Loading ...
Sorry, an error occurred while loading the content.

Re: MacOS X11 GVIM, :!cmd& misbehaves (workaround and "fix")

Expand Messages
  • Claus Reinke
    ... I don t have the output of :version for the Macs at hand, sorry. ... Well, the problem only occurs in the X11 GUI version. The terminal variant was for
    Message 1 of 2 , Jul 4 11:52 AM
    • 0 Attachment
      > > There seems to be a problem with MacOS X11 GVIM (not preinstalled;
      > > the default install method seems to give some version of 6.1) executing
      > > external commands in the background.
      > So what version are you using then?

      I don't have the output of :version for the Macs at hand, sorry.

      > It works fine for me. That is, it messes up the display after three
      > seconds (not fine :-). I only tried this in a Terminal.

      Well, the problem only occurs in the X11 GUI version. The terminal variant
      was for illustration of how it should work.

      > 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.

      > > I'm not a Mac user myself, and have never encountered this effect on
      > > any of the systems I use gvim on, which makes guessing/debugging
      > > rather difficult, but with the help of one friendly Mac user, we've found
      > > that there are no obvious differences in settings (neither in gvim nor in
      > > the bash it starts) wrt, say, a red hat linux system, on which gvim doesn't
      > > have this problem.
      > I don't see how this can ever work in any GUI version.

      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?

      The workaround

      :!(nohup xeyes &); sleep 1

      also seems to suggest this, as replacing "sleep 1" by "true" causes the
      construction to fail.

      > It should be the normal behavior for a process when it's input or output
      > pipe is terminated. Redirecting stdin, stdout and stderr should make it
      > work.

      Redirecting alone does not seem to help here, nor does just nohup, so
      I fear there is something else going on:

      :!(xeyes >/dev/null 2>/dev/null &)

      no

      :!(xeyes >/dev/null 2>/dev/null &); sleep 1

      no

      :!(xeyes >/dev/null 2>/dev/null &); sleep 5

      window frame appears for position selection, then disappears immediately

      :!(xeyes </dev/null >/dev/null 2>/dev/null &); sleep 10

      window can be positioned and appears, then disappears just before
      "hit enter.." prompt.

      :!(nohup xeyes &)

      no

      :!(nohup xeyes &);sleep 1

      yes! window appears and remains without problems..

      cheers,
      claus

      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:

      :set noguipty
      :xeyes&

      and, lo and behold, it works as expected! Going back to the default

      :set guipty
      :xeyes&

      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.. :-)
    • Bram Moolenaar
      Claus - ... 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
      Message 2 of 2 , Jul 4 12:44 PM
      • 0 Attachment
        Claus -

        > > 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
        first.

        > 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
        > :xeyes&
        >
        > and, lo and behold, it works as expected! Going back to the default
        >
        > :set guipty
        > :xeyes&
        >
        > 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!
        ARTHUR: What?
        BEDEVERE: It's The Legendary Black Beast of Aaaaarrrrrrggghhh!
        "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

        /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
        /// 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 ///
      Your message has been successfully submitted and would be delivered to recipients shortly.