On Sun, May 27, 2012 at 9:24 PM, Dan Douglas <orm...@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.ha...@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.