Re: handling of test == by BASH's POSIX mode

[Jon Seymour]

On Sun, May 27, 2012 at 9:24 PM, Dan Douglas <ormaaj@gmail.com> wrote:
> On Sunday, May 27, 2012 08:45:46 PM Jon Seymour wrote:
>> On 27/05/2012, at 17:39, Geir Hauge <geir.hauge@gmail.com> wrote:
>>
>> I guess the question is better phrased thus: what use case is usefully
> served by having bash's POSIX mode support a superset of test operators than
> other compliant POSIX shells?  As it stands, I can't use bash's POSIX mode to
> verify the validity or otherwise of a POSIX script because bash won't report
> these kinds of errors - even when running in POSIX mode.
>>
>
> There are no shells in existence that can do what you want. All major shells
> claiming to be POSIX compatible include some superset that can't be disabled.
> The only shell I have installed not supporting == in [ is dash, and there are
> so many scripts in the wild using == with [ it would be a miracle if your
> system didn't break because of it. Even the coreutils /usr/bin/[ supports ==.
>

I take your point that this isn't really a bash problem, but a POSIX
problem - POSIX hasn't provided a way to validate whether a script
only uses features that are required to be supported by POSIX
compliant interpreters. An example of this is the failure to prohibit
support for additional test operators which ultimately results in the
creation of interoperability problems between bash and dash - surely
not a good thing.

However, I think my question still remains unanswered - even if bash
is technically compliant with POSIX, what use case is usefully served
by having bash support a superset of the POSIX test operators while
executing in POSIX mode?

Yes, doing allows bash to execute an ill-defined superset of valid
POSIX scripts, but why is that useful - surely POSIX compliant mode
should only be required to execute strictly compliant POSIX scripts
and if we want to execute a superset, then we should explicitly
specify which superset we want to use, not hope that the POSIX
compliant interpreter installed on a machine happens to support that
superset.

You point about scripts failing when running under dash is a good one.
This is exactly my problem: I replaced /bin/sh -> dash with /bin/sh ->
bash because a 3rd party product installation script failed when dash
was the "POSIX" shell. Which is good - I fixed my installation
problem. Better would have been if the original developer had never
released the non-POSIX script in the first place, something that might
not have happened if the bash POSIX implementation was more
conservative. The fact that I didn't switch back to dash after I
installed the product eventually caused me to inject a non-POSIX test
== operator into some scripts I was working on for the git project -
again, something that would not have happened if bash's POSIX mode was
more conservative.

> Performing that kind of checking, rigorously, in a shell, would be impossible
> to do statically anyway. Any such lint tool is limited to lexical analysis
> which makes it not very useful for testing unless your script is perfectly
> free of side-efffects. And who writes side-effect free shell scripts?
>

> How would the shell check for the correctness of:
>
> "$(rm -rf somepath; echo '[')" x == x ]

I wasn't claiming that static checking would be viable. In fact, the
impossibility of static checking is precisely why it would be useful
to have real POSIX "compliant" interpreters that were as conservative
as possible in the syntax and commands they accepted at least in their
so-called POSIX mode. Currently, for example, if I want to test git sh
scripts, I need to ensure that /bin/sh is pointing at dash, because if
I use bash, errors of this kind can slip through. There really isn't a
more effective way for me to fix address this problem than by
abandoning bash as my POSIX shell and using dash instead since it's
POSIX mode does seem to be more conservative.

Given your example:

jseymour@ubuntu:~/tracked/git$ bash --posix -c '$(rm -rf "/tmp/foo";
echo "[")  x == x ] && echo yes'
yes

jseymour@ubuntu:~/tracked/git$ dash -c '$(rm -rf "/tmp/foo"; echo "[")
 x == x ] && echo yes'
[: 1: x: unexpected operator

bash --posix doesn't give me any clue that == isn't required to be
supported POSIX interpreters, but at least dash does.

jon.