Bourne Shell bug? Have a look..

[Martin Weitzel]

In article <1991Jan16.153557.15548 at ms.uky.edu> morgan at ms.uky.edu (Wes Morgan) writes:
[as followup to an article describing some strange behaviour
 with certain sequences of quoting in shell commands]

>...   I had thought that this might be a precedence
>problem.  If sh(1) assigned a higher precedence to " than to `
>or ', wouldn't it insert it at the appropriate place?  I tested
>this, and the script above works with missing ' as well as with
>missing " or `..........
>
>The FM on this system doesn't give a precedence listing for
>metacharacters in sh(1); does such a beast exist?

No, because it's not exactly a matter of precedence, but more some `state
machine'. Think of beeing in the normal state in the beginning and of
several different `quote states'. State transfers are more or less as
follows ("more or less" because I don't want to go into the details of
\-quoting and variable expansion in the form of ${name} here).

	NORMAL  \ ->	QUOTE   any ->	NORMAL
	NORMAL	' ->	SQUOTE	' ->	NORMAL
	NORMAL  ` ->	IQUOTE	` ->	NORMAL
			IQUOTE	\ ->	Q_IQOUTE any ->	IQUOTE
	NORMAL  " ->	DQOUTE	" ->	NORMAL
			DQUOTE	\ ->	Q_DQOUTE any ->	DQUOTE
			DQOUTE	` ->	I_DQUOTE ` ->	DQUOTE
					I_DQUOTE " ->	NORMAL

The last one is one of the observed "strangenesses" - S.R. Bourne could
also have choosen to consider this an syntax error, but he didn't and
simply transfered back to the normal state.

Some may argue that the above list isn't complete and that there
are also transfers for " in state IQUOTE (say, to D_IQUOTE) but
that isn't necessary: The whole contents of an IQOUTE-section of
the command line is handed more or less unchanged% to a separate
shell process an re-interpreted in this new context. All other quotes
are honored there and are no business of the shell that parses a line
which contains `..."..."...` .

Finally note that the shell conserves the DQUOTE-edness (oh, what a cute
word have I just coined here :-)) of any part of the command line until
command substitution is done%%. Effectively this means that the chars
which are written to standard out from any command within `....` 
may go into a quoted context, (if the `...` appeared *within* "......")
or not (if the `...` appeared *not* within ".......").

% : The parent shell *has* some business with \-quotes within `....`, which
    it must take care of before it hands the line to the other shell.
%%: The same is true for variable subsitituion, i.e. all the $-constructs.

People: The Bourne-Shell IS understandable. In fact I found it to be more
regular than a number of other languages! But you mustn't look at it with
fixed ideas of what "must" be going on (e.g. which precedence have different
quotes?) but try to answer the question "What may be the rules behind the
behaviour I observe?". The number of rules you'll find is amazingly small -
though some people have a strange tendency to clutter things up with a lot
of exceptions, just to make things fit to their way of thinking. (To Wes,
who posted the question: It's *not* you I have in mind here.)

Oh, I've a nice small brain-teaser (sp?) for those who made it up to
here. You know (or maybe you are just about to learn here :-)) that
I/O-redirection can be given *anywhere* in the command line, i.e.
that the following three command lines are equivalent:

	echo hello >file
	echo >file hello
	>file echo hello

You further know (or again you just learn it), that there can be more
than one redirection per line:

	echo hello >file foo >baz

Now: Which redirection is the one that is finally in effect when the
programm (the `echo' in the above example) runs, if you combine both
of the above "strange" ways to do I/O-direction? (What I want is not
the answer to a specific example, but the general rule!) I'll post the
answer in a week or so if noone solves this).
-- 
Martin Weitzel, email: martin at mwtech.UUCP, voice: 49-(0)6151-6 56 83