From: Bart Schaefer <schaefer@brasslantern.com>
To: zsh-users@zsh.org
Subject: Re: Calling interactive command inside widget
Date: Wed, 13 Apr 2016 10:55:32 -0700 [thread overview]
Message-ID: <160413105532.ZM31657@torch.brasslantern.com> (raw)
In-Reply-To: <20160413094152.660d42a9@pwslap01u.europe.root.pri>
On Apr 13, 9:41am, Peter Stephenson wrote:
}
} There's nothing much to go wrong in this ultra-simple example. I would
} suspect it's a problem not visible here, e.g. something associated
} with less like the LESSOPEN variable has gone haywire. To investigate,
} try setting PAGER=more and see if that works.
I can reproduce from zsh -f on my older Ubuntu -- here is xtrace output:
burner% ls +my-run-help:2> words=( ls )
+my-run-help:3> [[ ls == sudo ]]
+my-run-help:7> man ls
Missing filename ("less --help" for help)
+my-run-help:9> zle reset-prompt
burner% which man
/usr/bin/man
Exporting PAGER=more silences the error but does not display a man page.
I have no LESSOPEN variable.
I replaced "man" with a function wrapper that captures strace and then
ran "man" from the command line and again from the widget. Both times
"man" runs "pager -s" (which is a symlink through /etc/alternatives to
"less").
However, in the widget case, open("/dev/tty") returns 0, implying that
the standard input is closed, whereas in the command-line case the same
open() returns 3. [This is from inside the forked "less".]
Looking more closely, "man" itself is invoked with standard input closed
which causes all sorts of confusion with its handling of pipes to all
the sub-processes it forks off (gunzip, nroff, etc.). You can trivially
reproduce the error with:
burner% man ls <&-
Missing filename ("less --help" for help)
burner% ( man ls | less ) <&-
col: Bad file descriptor
This seems like a bug in "man" that should be reported to somebody, at
least Ubuntu if not upstream to Debian.
Meanwhile to fix the widget, just re-open /dev/tty:
my-run-help () {
words=(${=BUFFER})
if [[ $words[1] = sudo ]]
then
run-help $words[2]
else
run-help $words[1]
fi < /dev/tty
zle reset-prompt
}
You may want to throw a "zle -I" in there, but perhaps reset-prompt makes
it unnecessary.
next prev parent reply other threads:[~2016-04-13 17:55 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-12 21:58 Evgeny Zajcev
2016-04-13 8:41 ` Peter Stephenson
2016-04-13 17:55 ` Bart Schaefer [this message]
2016-04-16 8:21 ` frederik
2016-04-20 8:44 ` Sebastian Gniazdowski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=160413105532.ZM31657@torch.brasslantern.com \
--to=schaefer@brasslantern.com \
--cc=zsh-users@zsh.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).