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

Re: MacOS X11 GVIM, :!cmd& misbehaves

Expand Messages
  • Bram Moolenaar
    ... So what version are you using then? ... It works fine for me. That is, it messes up the display after three seconds (not fine :-). I only tried this in a
    Message 1 of 2 , Jul 4, 2004
    • 0 Attachment
      Claus Reinke wrote:

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

      > E.g.,
      > :!xeyes
      > works as expected, but
      > :!xeyes&
      > doesn't seem to work at all. Same problem for starting non-x11
      > processes in the background:
      > :!sleep 3;ls
      > works, but
      > :!(sleep 3; ls)&
      > doesn't.

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

      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.

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

      > Also, there is a rather odd work-around, namely:
      > :! (nohup xeyes &) & sleep 5
      > Both nohup and waiting after fork are necessary (using ';' instead of
      > bitwise-and '&' also works, as does the combination of redirecting all
      > i/o to /dev/null and waiting).
      > This suggests that this particular variant of gvim manages to preempt
      > the child process before it can get started/fully detached, but I'm not
      > at all sure about my hypotheses anymore:-(

      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

      User: I'm having problems with my text editor.
      Help desk: Which editor are you using?
      User: I don't know, but it's version VI (pronounced: 6).
      Help desk: Oh, then you should upgrade to version VIM (pronounced: 994).

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