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

Re: Reading from stdin

Expand Messages
  • Walter Briscoe
    In article of Wed, 2 Oct 2002 21:37:04 in , Bram Moolenaar writes ... I infer that todo.txt is
    Message 1 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 2 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.