On Mon, Apr 23, 2018 at 01:37:31PM +0200, Vincent Lefevre wrote: > On 2018-04-20 17:01:50 -0500, Derek Martin wrote: > > On Thu, Apr 19, 2018 at 08:24:43PM +0200, Vincent Lefevre wrote: > > > On 2018-04-17 14:28:17 -0500, Derek Martin wrote: > > > > > > > > [ -f $file -o -d $file ] > > > > > > AFAIK, -o is not portable and has been marked obsolescent. > > > You should write: [...] > For POSIX, this is an XSI extension. Thus not all POSIX shells might > support it. And in practice, its use in the general case is error > prone and the behavior depends on the shell. So, the best thing is > probably to have it removed in the future.
We have multiple equivalent solutions that should work everywhere, so again I'm continuing here purely as an academic exercise... The short version is things that are deprecated rarely get removed in practice, because Legacy. The longer version: There's what the standard says, and there's what is implemented in reality. Case in point: RFC 2047 headers. The spec specifically forbids them in certain headers, but due to a certain badly-behaved corporate entity forcing our hand to maintain compatibility (and in this case, not unreasonably I might add), the world has pretty universally implemented them in those headers anyway. This case is rather like that... the compound comparison was implemented in the original Bourne shell, and any shell that wanted to maintain compatibility (i.e. all of them, if they were based on Bourne syntax) had to implement that syntax to be compatible. I understated this earlier, but I personally used to use this syntax frequently in my shell scripts, which I have written on and/or ported to Ultrix, OSF/1 (or Dec Unix), HP-Ux 9, HP-UX 10+, SunOS, Solaris, Bash (on many platforms), and probably a few I'm forgetting. It's prohibitive to determine exhaustively its availability, but if there were a Bourne-like shell where this syntax was not available, I would be extremely, extremely suprised. Removing it has the potential to break thousands if not millions of shell scripts. And after all, who pays such close attention to the standard specs? To be perfectly honest Vincent, in my many years working in tech, you are quite literally the only person I've come across that does... [Then again, I made the same arguments about binutils removing the -[number] option to head and tail, and the maintainers went ahead and did it anyway. Of course, they finally realized their mistake, and PUT IT BACK IN.] In general, the only way the compount -o wouldn't work is if you write some syntax where the shell can't disambiguate the binary operator from the unary operator. It's actually somewhat hard to do this unintentionally, and easy to avoid... The primary way this would happen is if you didn't quote a shell variable which was empty, though that will often also cause other related syntax errors. There are probably other ways. All of them can be avoided if you use parens to group your expressions (but you have to be careful to quote the parens properly). But the case where we'd use this clearly doesn't suffer from any of the possible pitfalls, provided any variables are quoted properly. On the other hand, as I've already hinted, the only known case of -e not working is on an OS which is itself woefully obsolete, so I'd be just as happy if Mutt said "tough noogies, or patch it yourself." =8^) -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience.
pgpnEHp9GOmUl.pgp
Description: PGP signature