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

Reading from stdin

Expand Messages
  • Walter Briscoe
    I find myself in the fortunate position of having no job. This frees me to use some time to tackle the odd vim problem. ... I decided to look at: 8 When
    Message 1 of 4 , Oct 2, 2002
    • 0 Attachment
      I find myself in the fortunate position of having no job.
      This frees me to use some time to tackle the odd vim problem.
      :help todo suggests there is much to be done.

      I decided to look at:
      8 When stdin is not a tty, and Vim reads commands from it, an error
      should make Vim exit.

      I constructed a simple file q containing :q and ran vim -R < q.
      vim output "Vim: Warning: input is not from a terminal" and seized up.
      When I stepped through the code, I found that vim was attempting to read
      from the (unconnected) keyboard rather than stdin. This is on W2K built
      with vim built using Make_ivc.mak
      Should vim read from stdin rather than the keyboard until stdin is
      exhausted and then continue to read from the keyboard?
      --
      Walter Briscoe
    • Bram Moolenaar
      ... If you are interested, I have an updated todo list with a few more challenges... ... No, Vim reads commands from stdin. Only when nothing is read at all
      Message 2 of 4 , Oct 2, 2002
      • 0 Attachment
        Walter Briscoe wrote:

        > I find myself in the fortunate position of having no job.
        > This frees me to use some time to tackle the odd vim problem.
        > :help todo suggests there is much to be done.

        If you are interested, I have an updated todo list with a few more
        challenges...

        > I decided to look at:
        > 8 When stdin is not a tty, and Vim reads commands from it, an error
        > should make Vim exit.
        >
        > I constructed a simple file q containing :q and ran vim -R < q.
        > vim output "Vim: Warning: input is not from a terminal" and seized up.
        > When I stepped through the code, I found that vim was attempting to read
        > from the (unconnected) keyboard rather than stdin. This is on W2K built
        > with vim built using Make_ivc.mak
        > Should vim read from stdin rather than the keyboard until stdin is
        > exhausted and then continue to read from the keyboard?

        No, Vim reads commands from stdin. Only when nothing is read at all
        will it switch to reading stderr (when that's not a tty). When at least
        one character has been read and it can't read more Vim will exit.

        What happens for me is that a simple ":q" doesn't work, since there is
        no <CR>. It waits a moment and then exits with "Error reading input".
        ":q<CR>" simply exits Vim.

        Anyway, the original todo item was to make this work Vi compatible.
        Apparently the original Vi would exit when it encounters an error and
        the commands are not coming from a tty. Doing this properly requires
        checking what Vi does exactly and reproducing this in Vim.

        --
        hundred-and-one symptoms of being an internet addict:
        105. When someone asks you for your address, you tell them your URL.

        /// 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 ///
      • Walter Briscoe
        In article of Wed, 2 Oct 2002 21:37:04 in , Bram Moolenaar writes ... I infer that todo.txt is
        Message 3 of 4 , Oct 3, 2002
        • 0 Attachment
          In article <200210021937.g92Jb4804372@...> of Wed, 2 Oct 2002
          21:37:04 in , Bram Moolenaar <Bram@...> writes
          >
          >Walter Briscoe wrote:
          >
          >> I find myself in the fortunate position of having no job.
          >> This frees me to use some time to tackle the odd vim problem.
          >> :help todo suggests there is much to be done.
          >
          >If you are interested, I have an updated todo list with a few more
          >challenges...
          I infer that todo.txt is not updated by the patch process. I would value
          an update. I just selected the first problem I thought I might handle.

          >
          >> I decided to look at:
          >> 8 When stdin is not a tty, and Vim reads commands from it, an error
          >> should make Vim exit.
          >>
          >> I constructed a simple file q containing :q and ran vim -R < q.
          >> vim output "Vim: Warning: input is not from a terminal" and seized up.
          >> When I stepped through the code, I found that vim was attempting to read
          >> from the (unconnected) keyboard rather than stdin. This is on W2K built
          >> with vim built using Make_ivc.mak
          >> Should vim read from stdin rather than the keyboard until stdin is
          >> exhausted and then continue to read from the keyboard?
          >
          >No, Vim reads commands from stdin. Only when nothing is read at all
          I don't think that is true for the win32 console port.
          If I run vim -R, and connect to vim with the debugger when vim awaits
          input, I find the following stack:
          main, main_loop, normal_cmd, safe_vgetc, vgetc, vgetorpeek, inchar,
          ui_inchar, mch_inchar, tgetch, WaitForChar,
          #ifdef FEAT_CLIENTSERVER
          /* Wait for either an event on the console input or a message in
          * the client-server window. */
          if (MsgWaitForMultipleObjects(1, &g_hConIn, FALSE,
          dwEndTime - dwNow, QS_SENDMESSAGE) != WAIT_OBJECT_0)
          #else
          if (WaitForSingleObject(g_hConIn, dwEndTime - dwNow)
          != WAIT_OBJECT_0)
          #endif

          Something similar happens for vim -R < q. In that case, keystrokes do
          not find their way to the application. In UNIX, read() is done from
          read_cmd_fd which defaults to 0 (stdin). I think the Win32 port assumes
          control is only made from the console device and that vim -R < foo is
          not modelled. I think the win32 port should read from stdin rather than
          the console device when stdin is not the console device.

          >will it switch to reading stderr (when that's not a tty). When at least
          I see it reads commands from stderr when vim - is specified to imply
          that the "file" to be edited comes from stdin.

          >one character has been read and it can't read more Vim will exit.
          >
          >What happens for me is that a simple ":q" doesn't work, since there is
          >no <CR>. It waits a moment and then exits with "Error reading input".
          >":q<CR>" simply exits Vim.
          The behaviour I reported happens with both ":q\r\n" and ":q\r". My
          original file contains ":q\r\n" which I assume is equivalent to ":q<CR>"

          >
          >Anyway, the original todo item was to make this work Vi compatible.
          >Apparently the original Vi would exit when it encounters an error and
          >the commands are not coming from a tty. Doing this properly requires
          >checking what Vi does exactly and reproducing this in Vim.
          I suspect that todo.txt acts as an "aide memoire" for Bram and some
          information is lost between reporting a problem and its appearance in
          todo.txt. What do you mean by "what Vi does exactly"? Which Vi? I can
          probably find a Vi referenced in the POSIX 2001 standardisation process.
          (I seem to recall the author is Keith Borthwick.)
          Would that satisfy your purposes?
          >

          Meanwhile, I shall try another problem.
          --
          Walter Briscoe
        • Bram Moolenaar
          ... That is true. You need to set term to something else than win32 to read from stdin. But we would want vim
          Message 4 of 4 , Oct 3, 2002
          • 0 Attachment
            Walter Briscoe wrote:

            > >No, Vim reads commands from stdin. Only when nothing is read at all
            > I don't think that is true for the win32 console port.

            That is true. You need to set 'term' to something else than "win32" to
            read from stdin. But we would want "vim < file" to work like it works
            on Unix without that kind of tricks.

            > Something similar happens for vim -R < q. In that case, keystrokes do
            > not find their way to the application. In UNIX, read() is done from
            > read_cmd_fd which defaults to 0 (stdin). I think the Win32 port assumes
            > control is only made from the console device and that vim -R < foo is
            > not modelled. I think the win32 port should read from stdin rather than
            > the console device when stdin is not the console device.

            Something like that. Making it work more like how it works on Unix
            would be better. Would require trying it out and thinking about when
            this would break. Keep in mind things like resizing the console window
            (both on Win 9x and Win NT, it's quite different). That's the work to
            be done.

            > I suspect that todo.txt acts as an "aide memoire" for Bram and some
            > information is lost between reporting a problem and its appearance in
            > todo.txt.

            Yes, I summarize the relevant info. The todo list is quite long
            already.

            > What do you mean by "what Vi does exactly"? Which Vi? I can
            > probably find a Vi referenced in the POSIX 2001 standardisation process.
            > (I seem to recall the author is Keith Borthwick.)
            > Would that satisfy your purposes?

            No, POSIX attempted to describe what Vi does and their attempt is
            certainly not defining the actual implementations. The "real" Vi is
            what is shipped with older versions of Unix, such as Sun OS before they
            started Solaris. The version I'm mostly using to compare with is "Version
            3.7, 6/7/85". Other Vi versions have subtle differences.

            --
            hundred-and-one symptoms of being an internet addict:
            114. You are counting items, you go "0,1,2,3,4,5,6,7,8,9,A,B,C,D...".

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