On Fri, 2015-02-13 at 23:46 -0600, Les Mikesell wrote:> I think you are missing some very basic concepts here. First, the > shell likes to parse things separated by white space. Second, [ is a > synonym for test which is a build-in version of /bin/test, so try 'man > test' for the syntax of tests. And third, you generally should use > double quotes around variables in tests so they continue to exist as > an empty string if the variable happens to not be set.Thanks for that. I assumed if test 1 worked, so would test 2. Have re-run test 2 with> 16 if [ $file = "law00css" ] > 17 then > 18 echo $file > 19 echo "css" > 20 else > 21 echo "no css" > 22 fiand got> + '[' law45p07a01 = law00css ']' > + echo 'no css' > no css > + exitwhich is correct (for the first time). It seems that following your good advice and plonking spaces around the = has solved the problem. Thank you very much. Now I can go to bed a satisfied person :-) -- Regards, Paul. England, EU. Je suis Charlie.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Try using [[ and ]] rather than [ and ]. Under BASH the double form are reserved words with special meaning to the shell whereas the single form are just a synonym for test. Parsing and splitting rules are different, in particular word splitting and pathname expansion are not performed. Consider: #!/bin/sh myvar="" set -vx [[ -n $myvar ]] && echo "non-null" [ -n $myvar ] && echo "non-null" bash-4.2$ ./X [[ -n $myvar ]] && echo "non-null" + [[ -n '' ]] [ -n $myvar ] && echo "non-null" + '[' -n ']' + echo non-null non-null bash-4.2$ Note how in the second case $myvar has been parsed out of existence! On 14/02/15 05:54, Always Learning wrote:> > On Fri, 2015-02-13 at 23:46 -0600, Les Mikesell wrote: > >> I think you are missing some very basic concepts here. First, >> the shell likes to parse things separated by white space. Second, >> [ is a synonym for test which is a build-in version of /bin/test, >> so try 'man test' for the syntax of tests. And third, you >> generally should use double quotes around variables in tests so >> they continue to exist as an empty string if the variable happens >> to not be set. > > Thanks for that. I assumed if test 1 worked, so would test 2. > > Have re-run test 2 with > > >> 16 if [ $file = "law00css" ] 17 then 18 echo $file 19 >> echo "css" 20 else 21 echo "no css" 22 fi > > and got > >> + '[' law45p07a01 = law00css ']' + echo 'no css' no css + exit > > which is correct (for the first time). It seems that following your > good advice and plonking spaces around the = has solved the > problem. > > Thank you very much. Now I can go to bed a satisfied person :-) >-----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJU3xUdAAoJEAF3yXsqtyBlOHYQAN6KUdCq8YL+CIn+qTtFI++W mm44gmikluttmHl+llH17jaaaznakhZ+RmFjtygaHCSPZxxHZB9y5Dwv7czOaGpP ECbsCGUSHRa/yDZNcTy/5deXCta+mEeUkx105u6Usou+DA9XCYXqvWpNDPopNRJF Y4mwtgH7Jx2EgILgauECJFnuTtzHcZ2ps88d7H1nkJl49Q0EfmSPbcFrOoTJFeyM Qs2nl7OpPCQh/nNAuVW3S+aiYF+7Oe++tx3MaPYI6Y5GUhoAKmfM/Ab58iT+4ckV ha8tFY5cbCIPhKEzOTGK7rbEhmae9jgBl6s3HqaWiMrNPVrsKw/OLz0/V0j8S8Ib d2AOKJBaVYAZgYOW7yI9vhzO+zdUnhHXHHx9hT5kk7Jg5YI3nhMfotdVpOwZgu3i DewEa4bm4tR13ku54lYqmG1ehxyjxDUtPCF9DKyXriViGT+mpX7go4A3XPmnEk1n K48gQOHA4q4t1DTv6t3ATP3TkBlXWG0NzHprw9wB0LKgv00//9AJ5me+Mtwx8GTi g9Vg4jHH0EPu3WBBRnI5H3hFHRh/NtpSsEl0dGST5SpAUnuQikE6LXMmn1gw9bfa 8jsHL4mi/c70ugi4GQJyrhuZ/YIcIC6JSpugfRp7iqadJ2QiB4TmcgZl9R+7eAYu 4sK0nBvbVxh6ZQVrRhL0 =2980 -----END PGP SIGNATURE-----
On Fri, Feb 13, 2015 at 11:54 PM, Always Learning <centos at u64.u22.net> wrote:> >> And third, you generally should use >> double quotes around variables in tests so they continue to exist as >> an empty string if the variable happens to not be set. > > Thanks for that. I assumed if test 1 worked, so would test 2. > > Have re-run test 2 with > > >> 16 if [ $file = "law00css" ]You still missed the part about quoting variables. You quote plain strings to hold embedded spaces together (or single-quotes to avoid parsing metacharacters). You use double quotes around $variables so they don't disappear completely if the variable isn't set, causing a syntax error. To understand it completely you need to know the order of operations as the shell makes multiple passes over the line, parsing, processing metacharacters, and expanding variables. And I don't know where to find a concise description of that any more. -- Les Mikesell lesmikesell at gmail.com
Once upon a time, Les Mikesell <lesmikesell at gmail.com> said:> On Fri, Feb 13, 2015 at 11:54 PM, Always Learning <centos at u64.u22.net> wrote: > >> 16 if [ $file = "law00css" ] > > You still missed the part about quoting variables. You quote plain > strings to hold embedded spaces together (or single-quotes to avoid > parsing metacharacters). You use double quotes around $variables so > they don't disappear completely if the variable isn't set, causing a > syntax error. To understand it completely you need to know the order > of operations as the shell makes multiple passes over the line, > parsing, processing metacharacters, and expanding variables. And I > don't know where to find a concise description of that any more.The thing to remember is that originally, the left square bracket [ was an external command (an alias of the "test" command). The shell interpreter just ran commands and tested the output. So, consider everything past the "if" as a single command, and treat it accordingly (so quoting arguments just like you would to "ls" or something). So, in the above line, $file would be expanded by the shell as part of command argument processing, and it is empty/not set, the command would be run as: [ = law00css ] That's invalid syntax. If instead, you call it with $file in quotes: [ "" = law00css ] That's valid syntax (and then tests as false). -- Chris Adams <linux at cmadams.net>
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 14/02/15 16:53, Les Mikesell wrote: <snip>> To understand it completely you need to know the order of > operations as the shell makes multiple passes over the line, > parsing, processing metacharacters, and expanding variables. And > I don't know where to find a concise description of that any more.man bash, about 900 lines down under "EXPANSION". -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJU34eBAAoJEAF3yXsqtyBlNuYP/iPLOPY/SbXeGgpZOnJKZ3qH U7cnh56unXT3pTwQ8podSDNbLtiSOt8R729JFpNMwNb4Bzf9XFGaDyCn11DIdOuU RpuZ72NFxC8ezPcWlzvlYZuNRDIso4iQbHt5BjEutJ7RfSOdl+FoUdtXpXYATtaB YB4UQMShFVAr2AeNbJd/IuOopYSplZwd2qJXpAq0cZwtTWjbTkQG4zJOWIAip1kM 0q+5u3BKrP6ZEY7fWDhdCcJFZRRv+zAQaEnz42WUmEOROziF9sWzSxLOug87diA0 WcdEIoiNTuprFIeuICJvzTL1AhhjcYgm8+zBUb+xKpbBpJePQOtJ7Wd3RbkgEFhe 66hSNbLvYovqHgmz9E4H12ZnYW4JTmV8UE842JoliWqfNaD6v9wwaDmISekqm9jS 3f7Oc4fC7O+xao77T2jIHW4syMmG5Fdt8enyTR4QkRnx6W6sSTR6JKjii9GGo6P0 j5mA31KDQQyrJU6WqjL2TFgdZTF2zuL65xtEzxcWumpkqi6TaJodSnkIRH+ldgdg medZ910pxmJphojST0dsefJeptJfTw8qq16siatqj5r3+c6mUjTRRHkVVTyrlYHf 2h0t3ax+pQq0Fa9zx7Y0wIS+Qg8ihFC4XLJOQ+RI1WkG2jPCsaUHtkCYQxiZ/VK9 HOoe2d0MAGmNc4Yy2ex/ =UeON -----END PGP SIGNATURE-----