Re: command line processing order

[arnold@cc.gatech.edu (Arnold Robbins)]

On 5 July 1994, Arnold Robbins wrote:
> > This bit me the other day:
> > 
> > ; ls
> > a	b	c	d
> > ; cat * > foo
> > cat: input foo is output
> > 
> > The wildcard expansion is happening *after* the I/O redirection. The Bourne
> > shell and Byron's rc both do the wildcard expansion first, and I think this
> > is the right way to go.
> 
> Date: Tue, 29 Nov 1994 20:33:13 -0500
> From: haahr@netcom.com (Paul Haahr)
> Subject: Re: command line processing order
> 
> This would be a hard thing to change.  In raw es (try es -nx) the
> command becomes
> 
> 	{%create 1 <={%one foo} {cat *}}
> 
> which pretty much determines the sequence.  %create doesn't have the
> option to glob the command, create the file, and then execute.  (In
> fact, it's not even as simple as that description implies.)

I would argue that this really makes a strong case to bring globbing
out to the user level. It should become

	# pardon the pseudo-syntax, I've forgotten a lot of the details
	local (files = <={%glob *})
		{%create 1 <={%one foo} {cat $files }}

This would cause the globbing to happen first.

Maybe it could be done like this now, using `{ echo * } although then
you have issues of file names with spaces in them, etc. 

Hmmm:
	local (ifs = ; files = `{ echo * })
		{%create 1 <={%one foo} {cat $files }}

ANYWAY. The point is that I still think globbing should be done first,
and it could probably be managed.

> Interestingly enough, the Bourne shell really does seem to do the
> operations in the order that you specify:
> 
> 	$ >foo cat *
> 	Input/output files 'foo' identical
> 	$ 
> 
> Neither es nor rc preserves this much faithfulness to the order of
> coponents of a command line.

I agree that this is bogus; rc is "most correct" in this instance.
Interestingly enough, ksh gets this right.

Let me say that I, for one, am very happy to see that you're diving back
into es, and I'm looking forward to that "next release"!

Arnold