Re: execcmd() reordering

["Bart Schaefer" <schaefer@candle.brasslantern.com>]

On May 31, 12:55pm, Zoltan Hidvegi wrote:
} Subject: Re: execcmd() reordering
}
} > Oh, absolutely!  Does this change mean I can't interrupt long globs???
} > This would be terrible - esp. if the glob goes into a loop.
} 
} Do not worry.  Zsh never forked for builtins and you were able to interrupt
} things like echo **/*.  This is not changed.

Well, it's changed a little:

zagzig% echo **/*		(wait a couple of seconds, ^C)
zsh: bad pattern: **/*

It didn't used to complain about the pattern.  (Beta 19 without the
ececcmd patch has the problem; I haven't tried the execcmd patch yet.)

} ^Z will not work for
} suspending external commands but other than that there should be no
} noticable change

That's a very noticeable change, to me.

} unless something is backgrounded.

And then what?

} ^Z never worked for builtins and shell functions

I know, and that has always annoyed me.

} and the number of arguments that can be passed
} to external commands is always limited by the OS (although on modern
} systems this limit is very high).

What does that have to do with anything?  Zsh is still going to finish
the entire glob.  Even a very small glob is pretty slow on a filesystem
that's NFS mounted over a PPP link (as a pathological example).

On May 31,  1:58pm, Peter Stephenson wrote:
} Subject: Re: execcmd() reordering
}
} I didn't realise the problem with backgrounding recursive globs
} before, since I've never tried it.  I can't think of a way round other
} than using a subshell.  Bummer.  (Interruption is definitely OK,
} though.)

What if globbing was always treated as if it were a command sub?  E.g.
implement

	echo **/*

as

	echo $(echo **/*)

You could even make this behavior an option, SPAWN_GLOBS or some such,
and have an extendedglob metacharacter to use it for individual globs.

Now you've got a process handling the glob, so that can be stopped and
started without messing up the parent shell ... zsh would then have to
do some magic with the job table so that it could stash a partially-
parsed command string along with the job entry.

If the job later is foregrounded again, the current shell restarts the
globjob and picks up the parsing where it left off.

Backgrounding is tougher.  It *could* fork, resume the globjob, and then
the new subshell would pick up the parse; but then the subshell would be
a sibling of the globjob and wouldn't get the exit status notification.
I'd be satisfied with an error about not being able to background the
glob, as long as I could stop it, do something else briefly, and then
pick up again where I left off (rather than having to interrupt and then
start over from scratch).

(Maybe doing it as a command sub works around the problem of not being
able to stop non-builtins?  Then we'd at least be no worse off than we
were before.  I don't know what effect this reordering has on all the
other kinds of substitutions.)

-- 
Bart Schaefer                             Brass Lantern Enterprises
http://www.well.com/user/barts            http://www.nbn.com/people/lantern

New male in /home/schaefer:
>N  2 Justin William Schaefer  Sat May 11 03:43  53/4040  "Happy Birthday"