Re: command line processing order

[haahr@netcom.com (Paul Haahr)]

Arnold Robbins writes:
> > > ; 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.

> > 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
	# (so have I --Paul)
> 	local (files = <={%glob *})
> 		{%create 1 <={%one foo} {cat $files }}
> This would cause the globbing to happen first.

I knew someone would mention that, which is why I included my ``it's not
even that simple'' note.

The problem is that if there are multiple commands in a sequence, you
have to execute the first command before globbing the second.  E.g.,

	{ cat a* > b-files ; cat [ab]* } > foo

would be very hard to translate into something like what you suggest.

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

I'm not sure I think globbing should be done first, but I don't know how
to manage it without breaking the es execution model and getting in the
way of spoofing.

Paul