On Fri, Jun 1, 2012 at 11:33 PM, David Korn <[email protected]> wrote: > >> I just cannot understand how to interpret [ -n foo bar ] in ksh. ksh >> is a laguage, though it's not as powerful as other languages like >> perl. But ksh has its own syntax. Don't tell users the behavior of [ >> -n foo bar ] is undefined. If it's undefined, just give me a syntax >> error message. But [ -n foo bar ] does mean something because ksh >> thinks it's TRUE. >> > > It isn't a syntax error since [...] and test are not part of the shell > grammar but are separate utilities which may be built-in.
Normal users know little about, say, POSIX standards. They don't know if [ ] and test are part of the shell. They do know [ ] and test are built-in commands of ksh so just expect it to work in a natural and intuitive way. > > For exampe, how can the shell determine whether > [ "$@" ] > is a syntax error or not? > > What I could do is modify the test and [...] utilities to display > an error for every undefined case. However, I suspect that if I > do this, I will break some script that allowed this combination in > some version of test. My logic is very simple. If ksh cannot understand what [ -n foo bar ] really means, just give an error (syntax error or something else). The real bad thing is ksh considers something it cannot understand to be TRUE. And it's not necessary to give different errors for every undefined case. We can just say "Hey, I don't understand what you're talking about". I agree POSIX standards say some behaviors are undefined. But that usually means the features are implementation dependent. One specific implementation may choose not to implement the features but should implement the features in an undefined way. What would users expect from the undefined? > > It isn't even clear what message should be given. It the problem > that foo is not a operator, or is the problem that there is an > extra argument? > > It is possible that construct cases that have multiple interpretations. > > [[...]] on the other hand is part of the shell grammar. The operators > have to be recognized when parsing the script. Since word splitting > and file expansion are not done on arguments, the shell can tell how > many arguments there are. Instead of -a and -o which can be confused > as operands, [[...]] uses && and || which is part of the grammar. > > Other shells have picked up [[...]] so therefore I recommend that > you abandon test and [...] and use [[...]] instead. When I try to persuade others to use [[ ]] instead of [ ], I just tell them [[ ]] is better than [ ] under some circumstances. But I myself still use [ ] at times since it may save me a few keystrokes. After this discussion I would not tell others [[ ]] is better, instead, I can tell them [ ] is BAD. > > [[...]] was in ksh88 so it will have been around for nearly 25 years. > > David Korn > [email protected] _______________________________________________ ast-users mailing list [email protected] https://mailman.research.att.com/mailman/listinfo/ast-users
