On Sat, Jun 2, 2012 at 9:42 PM, Clark WANG <[email protected]> wrote: > 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
s/should/should not/ :) > 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
