Re: [vincent@xxxxxxxxxx: Bug#300470: zsh: trap mechanism on command-line length limitation with zargs-based fallback]

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Mar 19, 11:48pm, Clint Adams wrote:
> 
> Any thoughts on this idea?

I think it's unnecessary.  For interactive use, you can get most of the
same effect by using a "preexec" function (see e.g. zsh-users/4140, or
zsh-users/6463 which extends it) or other function wrappers.  The only
hard part is finding out what the argument length limit *is*, because
it's not available from e.g. the rlimits module.

Also, we've had discussions of exec "traps" in the past, and avoided
them because they're dangerous -- it becomes too easy to put the shell
in a state where it can't do anything at all.

Other comments:

> ----- Forwarded message from Vincent Lefevre <vincent@xxxxxxxxxx> -----
> 
> Here's an example: I type "rm **/*.foo". If the command line is not too
> long, the rm command is executed as expected. Otherwise, an alternate
> rm command (something like a builtin) is executed, using zargs. This
> alternate command should be able to cope with the various rm options,
> special filenames (e.g. starting with a '-') and error handling to hide
> the unwanted side effects of the rm wrapper.
> 
> Ditto for the other common commands (mv, cp, etc.).

"An alternate rm command" -- and mv, ln, etc. -- is already available in
the zsh/files module.  It "copes with all the various rm options" and is
not bound by the argument length limitations.  It actually is a builtin,
rather than just "something like" one, and it's distributed with the zsh
package.  ("cp" is currently missing, IIRC because it was decided that
a builtin couldn't do it any more efficiently than was already possible
with redirections, but it could be added.)