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"
