Zsh Mailing List Archive
Messages sorted by:
stderr from _call_program (Re: rsync --progress stops completion)
- X-seq: zsh-workers 33222
- From: Oliver Kiddle <okiddle@xxxxxxxxxxx>
- To: zsh-workers@xxxxxxx
- Subject: stderr from _call_program (Re: rsync --progress stops completion)
- Date: Tue, 23 Sep 2014 16:41:44 +0200
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.uk; s=s1024; t=1411483305; bh=SL7tDgTQ9WNy56YSg3pLUUfl38o+8bTZKZLn0lO67pg=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:In-reply-to:From:References:To:Subject:MIME-Version:Content-Type:Content-ID:Date:Message-ID; b=wiLZi/5a+/JV+u3k4FpWV0vPtztALj5/Oh8VQP4nT1VpFAqOsnJlGT4fO4rr22CFZf8KBC3Z7MuGOGBHF6mIy3PhvIlzd9VPnSMEo+R9LZf5tdGfbDj8oIIWuBcQFAeS4lha0zT1dkoUnu8axv14E0v/nD54+3rfXqPdOxZfYdw=
- In-reply-to: <140920174851.ZM5095@torch.brasslantern.com>
- List-help: <mailto:firstname.lastname@example.org>
- List-id: Zsh Workers List <zsh-workers.zsh.org>
- List-post: <mailto:email@example.com>
- Mailing-list: contact zsh-workers-help@xxxxxxx; run by ezmlm
- References: <firstname.lastname@example.org> <2002755.9ryFYYVtTN@note> <5418786F.email@example.com> <140916175124.ZM5742@torch.brasslantern.com> <firstname.lastname@example.org> <140917085133.ZM6725@torch.brasslantern.com> <541AA918.email@example.com> <140918093602.ZM7963@torch.brasslantern.com> <140918190130.ZM8366@torch.brasslantern.com> <firstname.lastname@example.org> <140920174851.ZM5095@torch.brasslantern.com>
On 20 Sep, Bart wrote:
> } _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".
I think we can safely append 2>/dev/null to the eval. If the command
(either from a zstyle preference or the function) uses 2>&1, output
should be captured:
% eval 'unknown 2>&1' 2>/dev/null
zsh: command not found: unknown
> 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?
Yes. Provided it is still possible to implement the remaining 10%.
> An explicit 2>/dev/null where? In the completion function use of
> _call_program? Except that anyone looking at function source as an
Yes, in the completion function.
> (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.)
Another possibility along similar lines would be to install a
command_not_found_handler function for the duration of the completion
system. Avoiding command not found errors is the main (but not only)
reason for redirecting stderr with _call_program.
We should also consider _complete_debug, perhaps directing stderr to the
log file instead of /dev/null.
Messages sorted by: