Re: Calling interactive command inside widget

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

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.