InFeeo
Global
technology-news
New
Language
Profile channel

@Didi

No bio yet.

Since 05.06.2026

Useless Use of Cat Award(altavista.com)
If you've been reading comp.unix.shell or any of the related groups (comp.unix.questions inter alia) for any amount of time, this should be a familiar topic. I made this web page on the topic primarily so I'd have a simpler URL than one of those ghastly Deja News searches to hand to people. I've tried to reconstruct Randal's standard form letter from looking at his postings (see end) and added some comments of my own. If you came here looking for material about abuse of feline animals, try this Alta Vista search instead. The oldest article Deja News finds is from 1995, but it's actually a followup to an earlier article. By Internet standards, this is thus an Ancient Tradition. Exercise: Try to find statistically significant differences between the followups from 1995 and the ones being posted today. (See below for a reconstruction of the Award text.) Briefly, here's the collected wisdom on using cat: Of course, as Heiner points out, using cat on a single file to view it from the command line is a valid use of cat (but you might be better off if you get accustomed to using less for this instead). In a recent thread on comp.unix.shell, the following example was posted by Andreas Schwab as another Useful Use of Cat on a lone file: (See below for a reconstruction of the Award text. It explains the issues clearly enough.) This is really a special case of Useless Use of Backticks but it deserves its own section because it's something you see fairly frequently. The canonical form of this is something like Depending a little bit on what exactly you have the variable for, this can be reduced at least to and there is often no real reason to even think of using echo in backticks when the simpler construct will do. (There is a twist: echo will "flatten" any whitespace in $variable into a single space -- unless you double-quote $variable, of course --, and sometimes you can legitimately use echo in backticks for this side effect. But that's rarely necessary or useful, and so most often, this is just a misguided use of echo.) There is another example in the next section, and a longer rant about Useless Use of Backticks further down the page. There is also a parallel, slightly different example on the Backticks Example page Very clever. Usually this is seen as part of a for loop: Here's a related but slightly more benign error (because echo is often built into the shell): Finally, as Aaron Crane points out, the result of ls * will usually be the wrong thing if you do it in a directory with subdirectories; ls will list the contents of those directories, not just their names. If something is reasonably coded, it might even already be setting its exit code to tell you whether it succeeded in doing what you asked it to do; in that case, all you have to check is the exit code: I used to have a really wretched example of clueless code (which I had written up completely on my own, to protect the innocent) which I've moved to a separate page and annotated a little bit. It expands on the above and also has a bit about useless use of backticks (q.v.) Here's a contribution I got from Aaron Crane (thanks!): (Of course, this is merely an example. If you have lsof it's probably a better solution to this particular problem; also the output of ps varies wildly from system to system so you might want to print something else than $2 and use completely different options to ps.) Remember that sed and awk are glorified variants of grep. So why use grep at all? True Story from Real Life: an older version of the GNATS system would think my real name was "System Operator" because it just went looking for the first occurrence of the letters e-r-a in the /etc/passwd file. (Well, actually, it thought my name was "System Era". It took me a while to figure out how it arrived at this somewhat whimsical conclusion. Incidentally, you also have to wonder why the author thought my real name was worth knowing, and if this is the right way to get that information. The end goal was to produce a template for an e-mail message -- perhaps my MUA would already know my real name, and even be able to produce nice e-mail headers for GNATS?) The cluelessness example (I've put it on a separate page) contains a lot of badly chosen backticks and a somewhat longer discussion of what exactly they can accomplish, and some ideas for how to do it differently. Obviously, backticks are a valid construction, and you can put them to good use in many shell scripts. I have simply noticed that newbie scripters often generously treat backticks as the hammer for all those nails they see. Incidentally, this is also one of the Very Ancient Recurring Threads in comp.unix.shell so don't make the mistake of posting anything that resembles this. In case something is still not obvious, the only disallowed file name characters under Unix are the null character and slash. If a file is called something like /tmp/moo/etc/passwd, normal find /tmp -print would output (I'll integrate it better with this page as soon as I have the time; I've been keeping it in my inbox for an embarrassing amount of time so I thought I'd better at least move it here where people can see it.) Despite the looks of this embarrassing section, I do appreciate comments and additional ideas for this page. Send me mail with your suggestions! I have a small collection of Unix links with some more information, too. )-: ylwols hguoht( depoh dah I naht retteb neve ,dekrow ti yltnerappA -- .egap "elpoeP looC" s'ladnaR no dedulcni ti teg ot si egap siht fo esoprup elohw eht ,yllaer oN
CoRecursive Interview with Paul Lutus, the Author of Apple Writer(youtube.com)
Today's episode is about remote work. Well, sort of. I found someone with a different perspective on remote work and a fantastic story to share, Paul Lutus. I think that he might be the original remote software developer. He left California behind for a lower cost of living in Oregon. And from Oregon, he developed software for Apple. But the kind of surprising thing is he did this in the 1970s! And he did it so well he became rich and even briefly quite famous.
The Isomorphic Labs Drug Design Engine unlocks a new frontier beyond AlphaFold(linkedin.com)
Today, we are excited to share an update on our progress towards a new frontier of drug design. We have unlocked a new paradigm of predictive accuracy in understanding our biomolecular world, allowing us to rationally design new medicines on a computer with unprecedented understanding and precision.
Streaming Encryption (2014)(tools.ietf.org)
Encrypting streams (27 Jun 2014) When sending data over the network, chunking is pretty much a given. TLS has a maximum record size of 16KB and this fits neatly with authenticated encryption APIs which all operate on an entire message at once. But file encryption frequently gets this wrong. Take OpenPGP: it bulk encrypts the data and sticks a single MAC on the end. Ideally everyone is decrypting to a temporary file and waiting until the decryption and verification is complete before touching the plaintext, but it takes a few seconds of searching to find people suggesting commands like this: gpg -d your_archive.tgz.gpg | tar xz With that construction, tar receives unauthenticated input and will happily extract it to the filesystem. An attacker doesn't (we assume) know the secret key, but they can guess at the structure of the plaintext and flip bits in the ciphertext. Bit flips in the ciphertext will produce a corresponding bit flip in the plaintext, followed by randomising the next block. I bet some smart attacker can do useful things with that ability. Sure the gpg command will exit with an error code, but do you think that the shell script writer carefully handled that case and undid the changes to the filesystem? The flaw here isn't in CFB mode's malleability, but in OpenPGP forcing the use of unauthenticated plaintext in practical situations. (Indeed, if you are ever thinking about the malleability of ciphertext, you have probably already lost.) I will even claim that the existance of an API that can operate in a streaming fashion over large records (i.e. will encrypt and defer the authenticator and will decrypt and return unauthenticated plaintext) is a mistake. Not only is it too easy to misunderstand and misuse (like the gpg example above) but, even if correctly buffered in a particular implementation, the existance of large records may force other implementations to do dangerous things because of a lack of buffer space. If large messages are chunked at 16KB then the overhead of sixteen bytes of authenticator for every chunk is only 0.1%. Additionally, you can safely stream the decryption (as long as you can cope with truncation of the plaintext). Although safer in general, when chunking one has to worry that an attacker hasn't reordered chunks, hasn't dropped chunks from the start and hasn't dropped chunks from the end. But sadly there's not a standard construction for taking an AEAD and making a scheme suitable for encrypting large files (AERO might be close, but it's not quite what I have in mind). Ideally such a scheme would take an AEAD and produce something very like an AEAD in that it takes a key, nonce and additional data, but can safely work in a streaming fashion. I don't think it need be very complex: take 64 bits of the nonce from the underlying AEAD as the chunk number, always start with chunk number zero and feed the additional data into chunk zero with a zero byte prefix. Prefix each chunk ciphertext with a 16 bit length and set the MSB to indicate the last chunk and authenticate that indication by setting the additional data to a single, 1 byte. The major worry might be that for many underlying AEADs, taking 64 bits of the nonce for the chunk counter leaves one with very little (or none!) left. That requires more thought before using it for real but, if you are ever building encryption-at-rest, please don't mess it up like we did 20 years ago. (Although, even with that better design, piping the output into tar may still be unwise because an attacker can truncate the stream at a chunk boundary: perhaps eliminating important files in the process.) Update: On Twitter, zooko points to Tahoe-LAFS as an example of getting it right. Additionally, taking the MAC of the current state of a digest operation and continuing the operation has been proposed for sponge functions (like SHA-3) under the name MAC-and-continue. The exact provenance of this isn't clear, but I think it might have been from the Keccak team in this paper. Although MAC-and-continue doesn't allow random access, which might be important for some situations.