> > In the GUI it will never work, since the output of the command isn't
> > caught, the pipe is broken as soon as you return to Vim. You will never
> > get the output.
> Guess I shouldn't have given the "ls" example, which was only meant for
> the terminal. xeyes doesn't do any terminal i/o, and in the real application,
> we do redirect stdout/stderr and do not use stdin.
Even though you do not use stdin, stdout or stderr, every application
has them. If the other end of the pipe breaks the application may exit.
You need something for error messages anyway. It's a pity that many GUI
applications don't show errors from stderr somehow.
> Perhaps it was a fluke then that it worked on the red hat system and, as I
> seem to recall, on a solaris system some months ago. I just tried the solaris
> system via remote X-connection over a slow modem line (I'm on a windows/
> cygwin system myself), and had the same problem as the Mac users -
> there seems to be some timing issue involved?
Vim closes the pipe to the application, perhaps before the shell gets a
chance to do something. It is unpredictable which application runs
> hmm. just remembered a phrase in 'man bash' about interactive shells:
> The shell exits by default upon receipt of a SIGHUP. Before
> exiting, an interactive shell resends the SIGHUP to all
> jobs, running or stopped. Stopped jobs are sent SIGCONT to
> ensure that they receive the SIGHUP.
> An interactive shell is one started without non-option argu-
> ments and without the -c option whose standard input and
> output are both connected to terminals (as determined by
> isatty(3)), or one started with the -i option.
> according to help, gvim means to start a non-interactive shell, and
> the '-c' shellcmdflag should guarantee that, but I also remembered
> coming across this guipty option. So I just tried this:
Why would Vim start a non-interactive shell? Vim doesn't know anything
about the command being executed. It may be interactive or not.
> :set noguipty
> and, lo and behold, it works as expected! Going back to the default
> :set guipty
> again fails. So it would seem that either the '-c' is not used, or
> bash is a bit too eager to misinterpret the presence of terminals
> and goes interactive, (or nothing of the sort.. :-)
I think the problem is that bash sends SIGHUP to processes started in
the background. That seems rather deadly to me.
Perhaps bash thinks that when a tty is used the shell is interactive. I
wouldn't care about that, doing "xeyes&" in an xterm and then quitting
the xterm should not kill the xeyes program.
[Another hideous roar.]
BEDEVERE: That's it!
BEDEVERE: It's The Legendary Black Beast of Aaaaarrrrrrggghhh!
"Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD
/// Bram Moolenaar -- Bram@...
/// Sponsor Vim, vote for features -- http://www.Vim.org/sponsor/
\\\ Project leader for A-A-P -- http://www.A-A-P.org
\\\ Buy at Amazon and help AIDS victims -- http://ICCF.nl/click1.html