Greg Ercolano wrote: > MacArthur, Ian (SELEX GALILEO, UK) wrote: >>> According to Ian, it should also work on IRIX platforms and >> >> You probably mean Greg here, I think? I haven't seen an Irix machine in >> years! > > Yeah, sometimes I turn it on to heat up the room, > or to run "soundeditor" to record stuff off the radio.. > >> As "''" constructs won't work as expected on native bash based platforms, >> which seems to be a conformity bug(as the first line force the script to >> be parsed with sh, so mike construction should have worked), I will apply >> and test the V2 modification (use of \" instead of ', no $(cmd) >> construction but `cmd` instead.) > > FWIW, and just to be clear, the original '$compile' (pre-patch) > didn't work on Irix either: > > # compile="/some/path/Foo Bar.cxx" > # prog="`basename '$compile' .cxx`" > # echo $prog > $compile > > ..and Mike's example for the Mac gives the same results on Irix: > > # foo=bar > # echo $foo > bar > # echo "$foo" > bar > # echo "'$foo'" > 'bar' > # uname > IRIX64 > > I get those results on Fedora3/bash as well.. so those three > platforms are all in agreement on that. > .
I tested the echo "'$foo'" and I was pleasantly surprised that it worked! Now, I used the bash shell to test this. It also works if I enter a bourne shell (# sh). I've always thought that single quotes turned off expansion. Well, I've learned something today! What I propose is that, when surrounded by double quotes, single quotes are used as literal characters. However, when used in command substitution, that feature is disabled. I guess that would make sense since the double quotes need to be escaped in order to work. I believe this is operator precedence. With double-quotes, the main shell evaluates the double quotes. However, by escaping the double-quotes, they are evaluated by the subshell. [EMAIL PROTECTED]:~> compile="my source.cxx" [EMAIL PROTECTED]:~> prog="`basename \"$compile\" .cxx`" [EMAIL PROTECTED]:~> echo $prog my source Note that the filename contains a IFS character (space). [EMAIL PROTECTED]:~> prog="`basename \'$compile\' .cxx`" basename: extra operand `.cxx' Try `basename --help' for more information. Note that single quote is escaped rather than escaping double-quotes. This appears to have yielded: prog="`basename my source.cxx .cxx`" which gives the error. Removing the space in the filename causes $compile to expand but the result is wrong: [EMAIL PROTECTED]:~> compile="mysource.cxx" [EMAIL PROTECTED]:~> prog="`basename \'$compile\' .cxx`" [EMAIL PROTECTED]:~> echo $prog 'mysource.cxx' Note prog still contains the file extension. Here's the evaluation ran in a script: [EMAIL PROTECTED]:~/bin> cat quotetst.sh #!/bin/sh set -x compile="my source.cxx" prog="`basename \'$compile\' .cxx`" echo $prog [EMAIL PROTECTED]:~/bin> ./quotetst.sh + compile='my source.cxx' ++ basename ''\''my' 'source.cxx'\''' .cxx basename: extra operand `.cxx' Try `basename --help' for more information. + prog= + echo Here's the output when double-quotes are used: [EMAIL PROTECTED]:~/bin> cat quotetst2.sh #!/bin/sh set -x compile="my source.cxx" prog="`basename \"$compile\" .cxx`" echo $prog [EMAIL PROTECTED]:~/bin> ./quotetst2.sh + compile='my source.cxx' ++ basename 'my source.cxx' .cxx #<---- This is like "'$foo'" + prog='my source' + echo my source my source It appears the the "'$foo'" does actually occur in quotetst2.sh! Who would have thunk it that quotes could be so much fun!! -- Alvin _______________________________________________ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
