Vim: Warning: Input is not from a terminal
Adam Monsen
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.
Adam Monsen
> of the first example, the vim "sans-dash" behavior?
Whoops, I should have searched a bit more before posting.
I found
:help 26.4
so I understand that the sans-dash calling convention is most useful
when using Vim in "batch" or "ex" mode.
Related, useful:
* http://vimdoc.sourceforge.net/htmldoc/usr_26.html
* http://superuser.com/questions/22455/vim-what-is-the-ex-mode-for-batch-processing-for
* http://www.kingcomputerservices.com/unix_101/purging_the_process_part_2.htm
Tony Mechelynck
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.
Best regards,
Tony.
--
The fortune program is supported, in part, by user contributions and by
a major grant from the National Endowment for the Inanities.
Gary Johnson
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
Tony Mechelynck
On a Unix terminal it's /dev/tty which may represent /dev/tty2 on a
Linux console or /dev/pty5 in konsole; on a Unix GUI I'm not sure if
/dev/tty represents :0, /dev/tty7 or nothing; on Windows it's not
/dev/tty but CON; on a Mac or on zOS I have no idea.
Less does not strive to be multi-platform or GUI, it is strictly a Unix
curses program. 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.
Best regards,
Tony.
--
hundred-and-one symptoms of being an internet addict:
69. Yahoo welcoms you with your own start page
Gary Johnson
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
Ben Schmidt
> "-" 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.
I wonder if it's something that could be changed by adding something to
'cpoptions' or whether Vim needs to decide about it before its startup
files are sourced.
Ben.
Joan Miquel Torres Rigo
>
> 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.
Then, how could you do something like this if stdin is always threated
as input file?:
echo ":wq"|vim foo.txt
Quite unuseful, ok. But we could add much more commands to the input stream.
Well, this is not the "normal" use of vim. But is it "echo something |
vim -" as well?
Regards.
--
Joan Miquel Torres__________________________________
Linux Registered User #164872
http://www.mallorcaweb.net/joanmiquel
BULMA: http://bulma.net http://breu.bulma.net/?l2301
Tony Mechelynck
> 2011/4/22 Gary Johnson<gary...@spocom.com>:
>>
>> 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.
>
> Then, how could you do something like this if stdin is always threated
> as input file?:
>
> echo ":wq"|vim foo.txt
>
> Quite unuseful, ok. But we could add much more commands to the input stream.
>
> Well, this is not the "normal" use of vim. But is it "echo something |
> vim -" as well?
>
>
> Regards.
>
Not with echo; but I have set up Mercurial to use "view -" as a pager
for the commands which generate long output (e.g. hg diff, hg glog, hg
cat) and this doesn't look like an "abnormal" use of Vim to me. I find
it much nicer than plain "less", or (worse) than having long streams of
text go past on the console with no pause for me to read them.
Best regards,
Tony.
--
hundred-and-one symptoms of being an internet addict:
72. Somebody at IRC just mentioned a way to obtain full motion video without
a PC using a wireless protocol called NTSC, you wonder how you never
heard about it
Gary Johnson
> 2011/4/22 Gary Johnson <gary...@spocom.com>:
> >
> > 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.
>
> Then, how could you do something like this if stdin is always threated
> as input file?:
>
> echo ":wq"|vim foo.txt
>
> Quite unuseful, ok. But we could add much more commands to the input stream.
I was not suggesting that stdin always be treated as an input file.
I was suggesting that the current means used to specify whether
stdin is treated as a data file or as a command stream is not the
only way it could have been done. For example, when stdin is not
connected to a terminal, Vim could assume that stdin should be
treated as a data file and could require a flag to specify that
stdin should be treated as a command stream.
I am also not suggesting that the current behavior be changed.
While it is not consistent with some other programs such as less,
and can be frustrating when I forget the '-', the current behavior
is reasonable, and I am getting better at remembering the '-'.
> Well, this is not the "normal" use of vim. But is it "echo something |
> vim -" as well?
I frequently pipe the output of some command into Vim to use Vim as
a pager, or to use the command output as the start of a new file, or
to edit and then execute some part of the command output.
Regards,
Gary
sc
> and can be frustrating when I forget the '-', the current
> behavior is reasonable, and I am getting better at
> remembering the '-'.
i have a script that remembers it for me:
<vhs>
#!/bin/bash
# hidden vim for use with sysin
vim -c 'call Hideme()' $@ -
</vhs>
and of course in .vimrc i have:
function! Hideme()
setlocal noswapfile
setlocal buftype=nofile
setlocal bufhidden=hide
endfunction
Hideme's cool for a lot of other functions too but that's
another story
for reading sysin i can do
ls -AlgG * | vhs
and i have a listing of the current directory in a vim
throw-away buffer -- incredibly useful
sc
Markus Osterhoff
> I was suggesting that the current means used to specify whether
> stdin is treated as a data file or as a command stream is not the
> only way it could have been done. For example, when stdin is not
> connected to a terminal, Vim could assume that stdin should be
> treated as a data file and could require a flag to specify that
> stdin should be treated as a command stream.
setups that rely on vim's being a filter like vi,ex,younameit.
> I frequently pipe the output of some command into Vim to use Vim as
> a pager, or to use the command output as the start of a new file, or
> to edit and then execute some part of the command output.
Maybe you want to look at the vim-pager-macros, on my system (Gentoo)
found here:
/usr/share/vim/vim73/macros/less.vim
/usr/share/vim/vim73/macros/less.sh
# Shell script to start Vim with less.vim.
# Read stdin if no arguments were given.
Would an alias like 'vl' for vim-less help you? Then you could use...
$ some --programme | vl
instead of
$ some --programme | vim -
> Regards,
> Gary
Regards,
mo