Zsh Mailing List Archive
Messages sorted by:
Re: rsync --progress stops completion
On Sep 19, 1:40pm, Oliver Kiddle wrote:
} > _cryptsetup - offers all options when completing after "-", but will
} > only allow one option to appear on the command line, as if all options
} > are mutually exclusive.
} I can't reproduce this.
I can't either, now. It may have had something to do with the set of
options I randomly selected for testing. Sorry for the false alarm.
} > _bzr - complains to stderr if bzr is not in $path
} > _surfraw - complains to stderr if surfraw is not in $path
} > The latter two make me think that _call_program should do something
} > with stderr -- probably just throw it away, rather than make every
} > caller add its own redirection.
} Note that a significant number of programs send their --help output to
} stderr. They're easily identified by searching for 2>& if the functions
} need adjusting to avoid breaking them.
Right, but that's an entirely different situation; if the --help output
goes to stder, then 2>&1 has to appear in the 'command' zstyle and in
the arguments passed to _call_program. I'm talking about "command not
found" sorts of errors, which just garble up ZLE to no good effect.
} _call_program could throw away
} stderr unless something like -e is passed. But should -e imply 2>&1?
No, this can't work. _call_program runs an "eval" on the value of the
"command" zstyle in preference to its argument list, so it has no way
of knowing whether it's appropriate to insert "2>&1".
On the other hand its silly for every single use of _call_program that
*does not* need 2>&1 to have to use 2>/dev/null.
There are 229 uses of _call_program in the completion tree:
16 redirect stderr to stdout
107 redirect stderr to /dev/null
106 do not redirect stderr at all
I'm guessing that all of those latter 106 *ought to* use 2>/dev/null,
because if they needed 2>&1 they'd be broken already.
If nearly half of all functions are getting this wrong, and 90%+ of
all functions need a certain behavior, that behavior probably should
be the default, don't you think?
} The advantage of an explicit 2>/dev/null is everyone knows what it does
} without checking the manual.
An explicit 2>/dev/null where? In the completion function use of
_call_program? Except that anyone looking at function source as an
example for a new function has a 50/50 chance of choosing the wrong
example, as things currently stand.
(One could argue that the whole completion system should be capturing
stderr somewhere and showing it to the user in a controlled way rather
than letting it scramble the display, but that's a larger issue.)
Messages sorted by: