Re: Reading from stdin
- In article <200210021937.g92Jb4804372@...> of Wed, 2 Oct 2002
21:37:04 in , Bram Moolenaar <Bram@...> writes
>I infer that todo.txt is not updated by the patch process. I would value
>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
an update. I just selected the first problem I thought I might handle.
>I don't think that is true for the win32 console port.
>> 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
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,
/* 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)
if (WaitForSingleObject(g_hConIn, dwEndTime - dwNow)
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 leastI 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.The behaviour I reported happens with both ":q\r\n" and ":q\r". My
>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.
original file contains ":q\r\n" which I assume is equivalent to ":q<CR>"
>I suspect that todo.txt acts as an "aide memoire" for Bram and some
>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.
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 wrote:
> >No, Vim reads commands from stdin. Only when nothing is read at allThat is true. You need to set 'term' to something else than "win32" to
> I don't think that is true for the win32 console port.
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 doSomething like that. Making it work more like how it works on Unix
> 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.
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
> I suspect that todo.txt acts as an "aide memoire" for Bram and someYes, I summarize the relevant info. The todo list is quite long
> information is lost between reporting a problem and its appearance in
> What do you mean by "what Vi does exactly"? Which Vi? I canNo, POSIX attempted to describe what Vi does and their attempt is
> 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?
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 ///