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

Re: stdin

Expand Messages
  • Bram Moolenaar
    ... This will break existing scripts that feed commands to Vim. Since Vim exits when it can t read from stdin, it should exit in most situations. If it
    Message 1 of 12 , Sep 4, 2002
    • 0 Attachment
      Piet Delport wrote:

      > The more i think about it, the more i think the current behaviour is
      > fine. The only change i'd be in favour of is:
      >
      > 1. When invoked normally (no - as arg), and STDIN is not a terminal,
      > exit with an error (like nvi), instead of going ahead with a warning.
      > 2. Add an option to force the old (i.e. current) behaviour. This could
      > either be a new option (something like --force-stdin-is-terminal),
      > or the existing -s option could be overloaded to accept "-" as
      > argument (i.e. "read commands from file STDIN")
      >
      > I think this is warranted because probably a *lot* more people are
      > getting annoyed by forgetting the - when editing STDIN (and ending up
      > with a hung terminal more than likely) than would be annoyed by having
      > to specify an extra option to make vim read commands from a non-terminal
      > STDIN. Bram?

      This will break existing scripts that feed commands to Vim. Since Vim
      exits when it can't read from stdin, it should exit in most situations.
      If it doesn't exit when reading from a pipe, perhaps that can be fixed.

      --
      ARTHUR: I command you as King of the Britons to stand aside!
      BLACK KNIGHT: I move for no man.
      The Quest for the Holy Grail (Monty Python)

      /// Bram Moolenaar -- Bram@... -- http://www.moolenaar.net \\\
      /// Creator of Vim -- http://vim.sf.net -- ftp://ftp.vim.org/pub/vim \\\
      \\\ Project leader for A-A-P -- http://www.a-a-p.org ///
      \\\ Lord Of The Rings helps Uganda - http://iccf-holland.org/lotr.html ///
    • Bram Moolenaar
      ... I find it strange that Vim hangs. For me this happens: $ echo something | vim Vim: Warning: Input is not from a terminal Vim: Error reading input,
      Message 2 of 12 , Sep 4, 2002
      • 0 Attachment
        Piet Delport wrote:

        > On Wed, 04 Sep 2002 at 10:03:43 +0200, Miroslaw Dobrzanski-Neumann wrote:
        > >
        > > I use to call vim in a pipe like this
        > >
        > > $ command | vim -
        > >
        > > unfortunately I always forget to type '-' after 'vim'.
        > > Afterwards both my shell and vim hang.
        >
        > I've had this bite me too on occasion. I've found that while ^C doesn't
        > work anymore, ^Z still suspends the hung vim. After suspending it and
        > getting my prompt back, i usually kill vim, and fix my typo.

        I find it strange that Vim hangs. For me this happens:

        $ echo something | vim
        Vim: Warning: Input is not from a terminal

        Vim: Error reading input, exiting...
        Vim: preserving files...
        Vim: Finished.

        Does your "command" keep on running perhaps?

        --
        f y cn rd ths thn y cn hv grt jb n cmptr prgrmmng

        /// Bram Moolenaar -- Bram@... -- http://www.moolenaar.net \\\
        /// Creator of Vim -- http://vim.sf.net -- ftp://ftp.vim.org/pub/vim \\\
        \\\ Project leader for A-A-P -- http://www.a-a-p.org ///
        \\\ Lord Of The Rings helps Uganda - http://iccf-holland.org/lotr.html ///
      • Bram Moolenaar
        ... It s in the todo list somewhere. It would require using :w - to write the buffer to stdout. -- BLACK KNIGHT: I move for no man. ARTHUR: So be
        Message 3 of 12 , Sep 4, 2002
        • 0 Attachment
          Miroslaw Dobrzanski-Neumann wrote:

          > And just one more suggestion
          >
          > If there is stdout and it is not a terminal vim should write current
          > buffer to stdout and terminate to allow fully pipe processing:
          >
          > $ command | vim -s commands | command2

          It's in the todo list somewhere. It would require using ":w -" to write
          the buffer to stdout.

          --
          BLACK KNIGHT: I move for no man.
          ARTHUR: So be it!
          [hah] [parry thrust]
          [ARTHUR chops the BLACK KNIGHT's left arm off]
          ARTHUR: Now stand aside, worthy adversary.
          BLACK KNIGHT: 'Tis but a scratch.
          The Quest for the Holy Grail (Monty Python)

          /// Bram Moolenaar -- Bram@... -- http://www.moolenaar.net \\\
          /// Creator of Vim -- http://vim.sf.net -- ftp://ftp.vim.org/pub/vim \\\
          \\\ Project leader for A-A-P -- http://www.a-a-p.org ///
          \\\ Lord Of The Rings helps Uganda - http://iccf-holland.org/lotr.html ///
        • Piet Delport
          ... I ve tried this again now, and i get the same behaviour. Seems i mis-remembered what happened. Some further testing refreshed my memory, and now recall
          Message 4 of 12 , Sep 4, 2002
          • 0 Attachment
            On Wed, 04 Sep 2002 at 20:31:56 +0200, Bram Moolenaar wrote:
            > Piet Delport wrote:
            >>
            >> I've had this bite me too on occasion. I've found that while ^C doesn't
            >> work anymore, ^Z still suspends the hung vim. After suspending it and
            >> getting my prompt back, i usually kill vim, and fix my typo.
            >
            > I find it strange that Vim hangs. For me this happens:
            >
            > $ echo something | vim
            > Vim: Warning: Input is not from a terminal
            >
            > Vim: Error reading input, exiting...
            > Vim: preserving files...
            > Vim: Finished.

            I've tried this again now, and i get the same behaviour. Seems i
            mis-remembered what happened. Some further testing refreshed my memory,
            and now recall that the hang happens when i interrupt the process that
            is feeding Vim.

            The first time this happened to me was when i wanted to pipe an
            attachment to Vim from within mutt, but mistyped "vim -" as "vim".
            I realized my mistake when i saw Vim report:

            Vim: Warning: Input is not from a terminal

            and immediately pressed ^C, which resulted in a seemingly wedged
            terminal. Everything i types (^C, ^D, :q!...) got echoed back on
            screen, except for ^Z, which suspended both mutt/vim. Resuming them
            didn't help any, so i eventually killed them off.

            Since then i managed cause more wedges like the above, but i can't
            remember the exact circumstances or commands involved.

            Some more ways to reproduce it:

            $ cat | vim

            Type some random text. Now, if you press ^D (EOF), Vim will exit with
            the message in your reply above. However, if you press ^C, it wedges.

            $ sleep 5 | vim

            Pressing ^C before the 5 seconds are over results in a wedge.

            --
            Piet Delport
            Today's subliminal thought is:
          • Miroslaw Dobrzanski-Neumann
            ... yes, for some large amount of time (ca. 30 secs); its cvs diff -- Miroslaw Dobrzanski-Neumann MOSAIC SOFTWARE AG Base Development and Research Tel
            Message 5 of 12 , Sep 4, 2002
            • 0 Attachment
              On Wed, Sep 04, 2002 at 08:31:56PM +0200, Bram Moolenaar wrote:
              >
              > Piet Delport wrote:
              >
              > > On Wed, 04 Sep 2002 at 10:03:43 +0200, Miroslaw Dobrzanski-Neumann wrote:
              > > >
              > > > I use to call vim in a pipe like this
              > > >
              > > > $ command | vim -
              > > >
              > > > unfortunately I always forget to type '-' after 'vim'.
              > > > Afterwards both my shell and vim hang.
              > >
              > > I've had this bite me too on occasion. I've found that while ^C doesn't
              > > work anymore, ^Z still suspends the hung vim. After suspending it and
              > > getting my prompt back, i usually kill vim, and fix my typo.
              >
              > I find it strange that Vim hangs. For me this happens:
              >
              > $ echo something | vim
              > Vim: Warning: Input is not from a terminal
              >
              > Vim: Error reading input, exiting...
              > Vim: preserving files...
              > Vim: Finished.
              >
              > Does your "command" keep on running perhaps?
              yes, for some large amount of time (ca. 30 secs);
              its "cvs diff"

              --
              Miroslaw Dobrzanski-Neumann

              MOSAIC SOFTWARE AG
              Base Development and Research
              Tel +49-2225-882-291
              Fax +49-2225-882-201
              Office: mne@...
              Home: mirek-dn@...
            • Bram Moolenaar
              ... These are good hints. I managed to reproduce this problem now. Using gdb to figure out what is going on I discovered the endless loop: fill_input_buf()
              Message 6 of 12 , Sep 5, 2002
              • 0 Attachment
                Piet Delport wrote:

                > > I find it strange that Vim hangs. For me this happens:
                > >
                > > $ echo something | vim
                > > Vim: Warning: Input is not from a terminal
                > >
                > > Vim: Error reading input, exiting...
                > > Vim: preserving files...
                > > Vim: Finished.
                >
                > I've tried this again now, and i get the same behaviour. Seems i
                > mis-remembered what happened. Some further testing refreshed my memory,
                > and now recall that the hang happens when i interrupt the process that
                > is feeding Vim.
                >
                > The first time this happened to me was when i wanted to pipe an
                > attachment to Vim from within mutt, but mistyped "vim -" as "vim".
                > I realized my mistake when i saw Vim report:
                >
                > Vim: Warning: Input is not from a terminal
                >
                > and immediately pressed ^C, which resulted in a seemingly wedged
                > terminal. Everything i types (^C, ^D, :q!...) got echoed back on
                > screen, except for ^Z, which suspended both mutt/vim. Resuming them
                > didn't help any, so i eventually killed them off.
                >
                > Since then i managed cause more wedges like the above, but i can't
                > remember the exact circumstances or commands involved.
                >
                > Some more ways to reproduce it:
                >
                > $ cat | vim
                >
                > Type some random text. Now, if you press ^D (EOF), Vim will exit with
                > the message in your reply above. However, if you press ^C, it wedges.
                >
                > $ sleep 5 | vim
                >
                > Pressing ^C before the 5 seconds are over results in a wedge.

                These are good hints. I managed to reproduce this problem now. Using
                gdb to figure out what is going on I discovered the endless loop:
                fill_input_buf() always returns a single CTRL-C after CTRL-C has been
                detected, also when no input could be read. And inchar() is reading all
                typeahead after the CTRL-C has been detected. It gets that one CTRL-C
                each time and loops forever.

                Try the following patch. A nice side effect is that after killing the
                command feeding the pipe, you can continue editing in Vim. Unless Vim
                did read something (you hit Enter), then it exits with an error.

                *** ../vim61.171/src/getchar.c Sun Aug 18 21:27:29 2002
                --- src/getchar.c Thu Sep 5 21:55:25 2002
                ***************
                *** 2577,2582 ****
                --- 2577,2584 ----
                /*
                * If we got an interrupt, skip all previously typed characters and
                * return TRUE if quit reading script file.
                + * Stop reading typeahead when a single CTRL-C was read,
                + * fill_input_buf() returns this when not able to read from stdin.
                * Don't use buf[] here, closescript() may have freed typebuf.tb_buf[]
                * and buf may be pointing inside typebuf.tb_buf[].
                */
                ***************
                *** 2585,2592 ****
                #define DUM_LEN MAXMAPLEN * 3 + 3
                char_u dum[DUM_LEN + 1];

                ! while (ui_inchar(dum, DUM_LEN, 0L) != 0)
                ! ;
                return retesc;
                }

                --- 2587,2598 ----
                #define DUM_LEN MAXMAPLEN * 3 + 3
                char_u dum[DUM_LEN + 1];

                ! for (;;)
                ! {
                ! len = ui_inchar(dum, DUM_LEN, 0L);
                ! if (len == 0 || (len == 1 && dum[0] == 3))
                ! break;
                ! }
                return retesc;
                }

                *** ../vim61.171/src/ui.c Sun Apr 28 22:00:14 2002
                --- src/ui.c Thu Sep 5 21:50:47 2002
                ***************
                *** 1708,1714 ****
                # endif
                if (len <= 0 && !got_int)
                read_error_exit();
                ! did_read_something = TRUE;
                if (got_int)
                {
                inbuf[inbufcount] = 3;
                --- 1708,1715 ----
                # endif
                if (len <= 0 && !got_int)
                read_error_exit();
                ! if (len > 0)
                ! did_read_something = TRUE;
                if (got_int)
                {
                inbuf[inbufcount] = 3;


                --
                5 out of 4 people have trouble with fractions.

                /// Bram Moolenaar -- Bram@... -- http://www.moolenaar.net \\\
                /// Creator of Vim - Vi IMproved -- http://www.vim.org \\\
                \\\ Project leader for A-A-P -- http://www.a-a-p.org ///
                \\\ Lord Of The Rings helps Uganda - http://iccf-holland.org/lotr.html ///
              • Piet Delport
                ... [...] ... [snip patch] The patch seems to work here. Vim exits cleanly when i press CTRL-C. I get some interesting new behaviour though. When i do cat |
                Message 7 of 12 , Sep 6, 2002
                • 0 Attachment
                  On Thu, 05 Sep 2002 at 23:14:00 +0200, Bram Moolenaar wrote:
                  > Piet Delport wrote:
                  >>
                  [...]
                  >>
                  >> Some more ways to reproduce it:
                  >>
                  >> $ cat | vim
                  >>
                  >> Type some random text. Now, if you press ^D (EOF), Vim will exit with
                  >> the message in your reply above. However, if you press ^C, it wedges.
                  >>
                  >> $ sleep 5 | vim
                  >>
                  >> Pressing ^C before the 5 seconds are over results in a wedge.
                  >
                  > These are good hints. I managed to reproduce this problem now. Using
                  > gdb to figure out what is going on I discovered the endless loop:
                  > fill_input_buf() always returns a single CTRL-C after CTRL-C has been
                  > detected, also when no input could be read. And inchar() is reading all
                  > typeahead after the CTRL-C has been detected. It gets that one CTRL-C
                  > each time and loops forever.
                  >
                  > Try the following patch. A nice side effect is that after killing the
                  > command feeding the pipe, you can continue editing in Vim. Unless Vim
                  > did read something (you hit Enter), then it exits with an error.
                  >
                  [snip patch]

                  The patch seems to work here. Vim exits cleanly when i press CTRL-C.

                  I get some interesting new behaviour though.

                  When i do "cat | vim" and press CTRL-Z, i get another wedge now (instead
                  of suspending both vim and cat). Unlike the CTRL-C wedge, nothing seems
                  to be able to get out of this one though, short of killing cat from
                  another terminal.

                  "sleep 10 | vim" + CTRL-Z[1] wedges similarly, but after the 10 seconds
                  pass, vim seems to recover and work normally.

                  My guess is that the CTRL-Z is suspending the feeding process, creating
                  a deadlock[3], and effectively orphaning the terminal until you can
                  rescue it by resuming/killing cat from another terminal. The sleep
                  version would recover on its own because it gets woken by an alarm
                  signal IIRC.


                  [1] only if the CTRL-Z is pressed *after* vim stops displaying the
                  warning message and goes into `termcap mode'[2]. When before this,
                  both sleep and vim get suspended normally.

                  [2] What's the correct terminology for this?

                  [3] where you can't unsuspend cat because no keyboard input gets
                  processed because cat is suspended...

                  --
                  Piet Delport
                  Today's subliminal thought is:
                • Bram Moolenaar
                  ... I can t reproduce this. For me CTRL-Z works as expected. ... Raw mode. In this mode the program must handle special keys itself. That s why CTRL-C
                  Message 8 of 12 , Sep 6, 2002
                  • 0 Attachment
                    Piet Delport wrote:

                    > The patch seems to work here. Vim exits cleanly when i press CTRL-C.
                    >
                    > I get some interesting new behaviour though.
                    >
                    > When i do "cat | vim" and press CTRL-Z, i get another wedge now (instead
                    > of suspending both vim and cat). Unlike the CTRL-C wedge, nothing seems
                    > to be able to get out of this one though, short of killing cat from
                    > another terminal.
                    >
                    > "sleep 10 | vim" + CTRL-Z[1] wedges similarly, but after the 10 seconds
                    > pass, vim seems to recover and work normally.

                    I can't reproduce this. For me CTRL-Z works as expected.

                    > My guess is that the CTRL-Z is suspending the feeding process, creating
                    > a deadlock[3], and effectively orphaning the terminal until you can
                    > rescue it by resuming/killing cat from another terminal. The sleep
                    > version would recover on its own because it gets woken by an alarm
                    > signal IIRC.
                    >
                    >
                    > [1] only if the CTRL-Z is pressed *after* vim stops displaying the
                    > warning message and goes into `termcap mode'[2]. When before this,
                    > both sleep and vim get suspended normally.
                    >
                    > [2] What's the correct terminology for this?

                    Raw mode. In this mode the program must handle special keys itself.
                    That's why CTRL-C doesn't kill Vim.

                    I can't reproduce this and can't guess what the problem is...

                    --
                    MESKIMEN'S LAW
                    There's never time to do it right, but always time to do it over.

                    /// Bram Moolenaar -- Bram@... -- http://www.moolenaar.net \\\
                    /// Creator of Vim - Vi IMproved -- http://www.vim.org \\\
                    \\\ Project leader for A-A-P -- http://www.a-a-p.org ///
                    \\\ Lord Of The Rings helps Uganda - http://iccf-holland.org/lotr.html ///
                  Your message has been successfully submitted and would be delivered to recipients shortly.