Problem with mutt version.sh script

Derek Martin invalid at pizzashack.org
Mon Apr 23 19:25:29 UTC 2018


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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.mutt.org/pipermail/mutt-dev/attachments/20180423/00dbfdc1/attachment.asc>


More information about the Mutt-dev mailing list