On 2011-04-22, Tony Mechelynck wrote:
> On 22/04/11 08:22, Gary Johnson wrote:
> >On 2011-04-22, Tony Mechelynck wrote:
> >>On 22/04/11 07:36, Adam Monsen wrote:
> >>>You've this mistake before, right?
> >>>
> >>>   cat /tmp/foo.txt | vim
> >>>
> >>>when you meant to do
> >>>
> >>>   cat /tmp/foo.txt | vim -
> >>>
> >>>Somewhere early in my Vim learning I figured out the latter, so I
> >>>usually don't repeat the mistake.
> >>>
> >>>But why *is* that even a mistake? What is the purpose/origin/history
> >>>of the first example, the vim "sans-dash" behavior?
> >>>
> >>>Seems like the "vim -" behavior (read text from stdin) would make
> >>>for a much more useful default.
> >>>
> >>
> >>Vim needs to read your keyboard commands from somewhere; so normally it
> >>reads them from stdin, or if in GUI mode and there is no stdin, then
> >>from the GUI (X11, Windows, etc.) keyboard dedvice. It's not like so
> >>many batch command-line utilities which take no interactive input but
> >>only command-line arguments, and thus can default to stdin if no
> >>specific input file is given.
> >>
> >>When Vim is not started with an editfile specified, it opens an empty
> >>[NoName] file: it doesn't take your keyboard input as raw file data to
> >>be edited later (maybe after you signal an end-of-file by hitting Ctrl-Z
> >>on Windows or Ctrl-D on Unix).
> >>
> >>In the special case when you specify stdin as input, Vim reads it all as
> >>an input file, marks it as modified except if readonly, and then starts
> >>reading your keypresses from somewhere, maybe stderr though it is
> >>somewhat strange to use the "error output device" for input.
> >
> >Couldn't vim just as easily use isatty(0) instead of "-" to
> >determine whether data is coming from stdin?  It has /dev/tty for
> >keyboard input.  I think that's what less does.
> >
> >Regards,
> >Gary
> >
> 
> On a Unix terminal it's /dev/tty which may represent /dev/tty2 on a 
> Linux console or /dev/pty5 in konsole;

On Unix, /dev/tty is an alias for whatever terminal you're connected
to.  Your actual terminal may be /dev/tty2 or /dev/tty3 or whatever,
but /dev/tty always refers to your current terminal.

> on a Unix GUI I'm not sure if /dev/tty represents :0, /dev/tty7 or
> nothing;

A GUI wouldn't have anything connected to stdin or stdout unless it
was launched from the command line with something connected to
stdin or stdout, as this example of a GUI program reading data
from stdin:

    $ echo hello | xmessage

> on Windows it's not /dev/tty but CON; on a Mac or on zOS I have no
> idea.

Of course, something other that /dev/tty would have to be used for
other OSs.  But 'more' on DOS is another example of a program that
doesn't have to be explicitly told that input is coming from stdin.
You can use 'more' to read a file with either "more foo.txt" or
"type foo.txt | more".

> Less does not strive to be multi-platform or GUI, it is strictly a Unix 
> curses program.

There are versions of less that run in a DOS console.  It doesn't
matter that it's not a GUI.

> IMHO it is simpler to use stdin for keyboard input 
> whenever you don't specify explicitly that stdin has the editfile 
> instead. For one thing there are no corner cases: either there is a lone 
> dash on the command-line and stdin is a file to be edited, or there 
> isn't and stdin is interactive commands.

I understand that Vim can also take editing commands from stdin, but
I'm sure that is done much less often than Vim is used to read the
output of some command.  Also, taking commands from stdin is usually
done in a batch/script file where it doesn't really matter how many
extra arguments to a command are needed--such files aren't written
as often as commands are executed from the keyboard.  So from an
efficiency and ergonomic perspective, as well as for consistency
with other Unix commands, it would make more sense when stdin is
connected to a pipe for "vim" to mean stdin has data to be read into
a buffer and for "vim -some_argument" to mean stdin has a command
stream.

If Vim had that behavior, I wouldn't find myself typing "some
pipeline | less", thinking, "No, I'd rather use vim", changing the
command to "some pipeline | vim", saying, "Darn. Forgot the '-'
again", and finally typing "some pipeline | vim -".

The point is that there is no functional reason that Vim has to use
"-" to mean that its buffer contents are coming from stdin.  My
guess is that Vim's use of "-" is another quirk resulting from its
historical connections to vi, ex and ed.

Regards,
Gary

-- 
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

Reply via email to