On Oct 9, 2010, at 10:25 PM, Julian Elischer wrote: > Ah grasshoppers... > > /me wonders if anyone will get the full significance of that.. > > > On 10/9/10 3:39 PM, Devin Teske wrote: >> On Oct 9, 2010, at 1:25 PM, Garrett Cooper wrote: >> >> >>> Why not just do... >>> >>> if [ "x$rc_conf_files" = x -o "x$varname" = x ] >>> then >>> return ${FAILURE-1} >>> fi >> I think you'll find (quite pleasantly) that if you intonate the lines... >> >> "rc_conf_files [is non-null] OR return failure" >> "varname [is non-null] OR return failure" >> >> Sounds a lot better/cleaner than the intonation of the suggested replacement: >> >> "if x plus rc_conf_files expands to something that is not equal to x OR >> x plus the expansion of varname is not x then return failure" >> > > > For what it matters, I'v enever found the [ "x$foo" = "x" ] construct to be > useful. > the quoting seems to work for everything I've ever worked on.
I agree... I think that the "x" syntax came around for when people were using non-quoted syntax... for example... [ x$foo = x ] is still very useful in that it prevents the error when $foo expands to "-e". However, enclosing the argument (as the 'x$foo' portion is really just the first argument to the '[' built-in) in quotes: [ "$foo" = x ] makes it so that the expansion is taken as: [ "-n" = x ] rather than: [ -n = x ] The former not causing an error, while the latter does. Quite functionally, at a C-level, if you have your array, ... argv[0] = "[\0"; argv[1] = "\"-n\"\0"; /* quoted syntax */ argv[2] = "=\0"; argv[3] = "x\0"; and argv[0] = "[\0"; argv[1] = "-n\0"; /* non-quoted syntax */ argv[2] = "=\0"; argv[3] = "x\0"; The C-code that switch'es on the argv element can tell the difference between a leading quote and a leading dash and does indeed do the right thing for all expansions of the variable within a double-quote block ("..."). Though, the non-quoted syntax should be avoided at all costs, imho unless you know for a fact that the expansion of the variable will never include a character from $IFS (defaults to space, tab, newline). If it does, then it'll evaluate to a new positional argument for the C-code. Take the following example: $ foo="abc = abc" $ [ $foo ] && echo true true $ foo="abc = 123" $ [ $foo ] && echo true # no output (not true) Whereas the quoted syntax: $ [ "$foo" ] will always evaluate to true because there is an implied "-n" operator for the case where the first-and-last positional argument is a double-quoted string, and... $ [ -n "$foo" ] always evaluates to true in the above cases for foo ("abc = abc" then later "abc = 123"). > ... > > Now One thing that should be bourne in mind (heh) is that > as there is a 'usual' form of format for perl there is one for sh as well so > it's not "polite" > to make one's sh code look like perl. :-) Perusing sh(1) today... found examples of the lazy operators: [ expr ] || expr [ expr ] && expr Search under "Short-Circuit List Operators" I'd say that the description therein is a green-light to treat sh like perl ^_^ > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org" -- Cheers, Devin Teske -> CONTACT INFORMATION <- Business Solutions Consultant II FIS - fisglobal.com 510-735-5650 Mobile 510-621-2038 Office 510-621-2020 Office Fax 909-477-4578 Home/Fax devin.te...@fisglobal.com -> LEGAL DISCLAIMER <- This message contains confidential and proprietary information of the sender, and is intended only for the person(s) to whom it is addressed. Any use, distribution, copying or disclosure by any other person is strictly prohibited. If you have received this message in error, please notify the e-mail sender immediately, and delete the original message without making a copy. -> FUN STUFF <- -----BEGIN GEEK CODE BLOCK----- Version 3.1 GAT/CS d(+) s: a- C++(++++) UB++++$ P++(++++) L++(++++) !E--- W++ N? o? K- w O M+ V- PS+ PE Y+ PGP- t(+) 5? X+(++) R>++ tv(+) b+(++) DI+(++) D(+) G+>++ e>+ h r>++ y+ ------END GEEK CODE BLOCK------ http://www.geekcode.com/ -> END TRANSMISSION <- _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"