[PATCH] *.sh: Fix kornsh-ism test(1) invocations

Bernhard Reutner-Fischer rep.dot.nop at gmail.com
Fri Sep 16 13:36:14 PDT 2022


On Fri, 16 Sep 2022 16:16:42 +0200
Dimitri Papadopoulos Orfanos <dimitri.papadopoulos at cea.fr> wrote:

> >> [...]
> >> But for all the rest plain test(1) is sufficient.  
> > 
> > What I'm really asking here is… what actual problem do these changes solve?
> > [...]  
> 
> These changes do not fix an actual runtime problem. Rather they fix a 
> sort of "code documentation" problem. The current code seems to imply 
> that regular expressions might be involved, because the compound 
> statement [[ ... == ... ]] means that the string to the right of the 
> operator is considered a pattern.
> 
> For regular strings, POSIX style [ ... = ... ] is the proper test to 
> use, because we want the string to the right of the operator to be 
> considered a string.
> 
> Besides it will trigger simpler and more efficient Bash code (plain 
> strings instead of patterns).
> 

For the most part yes.

But if you rely on non-standard "features" you stumble across cases
that are standard compliant.

Not an exhaustive list, of course, but some of the many i happen to
have encountered:
$ /bin/dash -c '[[ 1 == 1 ]] && echo true || echo false'
/bin/dash: 1: [[: not found
false
Boxen without MMU (or with, but constrained resources) simply will not
ship bash which weights in at > 1.2 Megabyte. This alone used to be a
full kernel plus userspace a couple of years back. But as the kernel
grew (abysmally) in size, the margin of 4MB, 8MB or even hugeish 16MB
available storage is usually not spent on a monster shell. You'd usually
use something reasonably sized, some 20k or 70k like hush or your own
shell that strive to work reasonably posix compliant to get the stuff
done small and fast.

A plain string comparison in a shell doesn't need to callout to a
javascript or perl helper, nor bash's [[ or some other heavy weight
fancy thing. It's just that. Keep it simple please.

thanks (and sorry for the rant above)



More information about the openconnect-devel mailing list