Well, I thought about this issue. It is really a bit tricky, and there are more inconsistencies in the shell I want to get rid of.
First, we have some weirdo, namely variables with blanks in it. So if we have
set a="a b"
Then, naturally,
command $a
results in "command" receiving two arguments, and
command "$a"
receiving one argument "a b".
If we set, however,
set a="*"a b*""
then
command $a
results in one argument, namely "a b". However, the V45 shell does for
command "$a"
also the same thing by first removing the outer quotes, hence giving effectively the same result. I believe this is wrong. As it is quoted, the quotes within the variable should be escaped, and hence the value preserved:
command "$a"
should call "command", but not with argument "a b", but with argument "*"a b*"", i.e. the quotes within the variable should be preserved.
As far as line feeds in variables are concerned: These can be really nasty. So if we have
set a="a*Nb"
and would then, without further modifications, call
command $a b
then the line feed within $a would terminate the line, and the command would never see the second argument. This is clearly undesired.
So I believe the following rule makes sense: If a variable is expanded within double quotes, it is expanded as a "binary variable", and the line feed stays within the double quotes, and is there - as part of the substitution process - replaced by a *N, so it is forwarded to the command.
If a variable is expanded outside of double quotes, the old rules apply and the variable is expanded as "text variable" and its contents is terminated at the first line feed, or \0, whatever comes first (this is how dos handles it).
I hope this makes sense...
A word about backticks: It is since ever that a line feed within backticks is replaced by a blank. This is also the case under Linux, and I believe it makes most sense in case a "list" command is put into the backticks. So I guess I keep it this way, unless somebody has a smart idea how to improve it without breaking too much.
Last but not least, we have one outsider, and this is the "rx" command. Unfortunately, this is not fixable as "rx" with arguments in quotes executes the script literally, i.e.
rx "say hello"
prints "HELLO" on the screen, whereas
rx say hello
executes the rexx script "say" (if it exists) with the argument "hello".
This all becomes a bit pathetic in case you have a volume named "say hello", as then the shell puts quotes around the volume name. Or to keep it simple, a rexx script on the "Ram Disk:". One cannot, possibly, execute it from there:
"Ram Disk:test.rexx"
on the shell will not work whatsoever, since the double quotes are needed to escape the volume name, but it changes the meaning of what "rx" attemts to do. Namely here not to execute a script on "Ram", but to execute the Rexx command "Ram" (which does not exist), with the argument "Disk:test.rexx". Bummer!
Replace "Ram Disk:" by "RAM:" and things work, but I guess Bill hasn't thought this one to the very end.
I hope there were people out here who could follow. This is all touchy business.