xargs and vi - "Input is not from a terminal"

Question

I have about 10 php.ini files on my system, located all over the place, and I wanted to quickly browse through them. I tried this command:

locate php.ini | xargs vi

But vi warns me Input is not from a terminal and then the console starts getting really weird - after which I need to press :q! to quit vi and then disconnect from the ssh session and reconnect to have the console behave normally again.

I think that I sort of understand what's happening here - basically the command hasn't finished when vi started so the command maybe hasn't finished and vi doesn't think that the terminal is in normal mode.

I have no idea how to fix it. I have searched Google and also unix.stackexchange.com with poor luck.

Answer 1

This question has previously been asked on the Super User forum.

Quoting from @grawity's answer on that question:

When you invoke a program via xargs, the program's stdin (standard input) points to /dev/null. (Since xargs doesn't know the original stdin, it does the next best thing.)

Vim expects its stdin to be the same as its controlling terminal, and performs various terminal-related ioctl's on stdin directly. When done on /dev/null (or any non-tty file descriptor), those ioctls are meaningless and return ENOTTY, which gets silently ignored.

Both the OS X/macOS/BSD and recent versions of GNU findutils' xargs (beginning with v4.6.0) have a -o option to address this exact scenario:

From the macOS/BSD man page:

-o Reopen stdin as /dev/tty in the child process before executing the command. This is useful if you want xargs to run an interactive application.

Hence, on macOS, you could use the following command:

find . -name "php.ini" | xargs -o vim

If you are stuck with an older version of GNU xargs, the following command will work. (Make sure to include the dummy string, otherwise it will drop the first file.)

find . -name "php.ini" | xargs bash -c '</dev/tty vim "$@"' dummy

The above solutions are courtesy Jaime McGuigan on SuperUser. Adding them here for any future visitors searching the site for this error.

Answer 2

vi $(locate php.ini)

Note: this will have issues if your file paths have spaces, but it is functionally equivalent to your command.
This next version will properly handle spaces but is a bit more complicated (newlines in file names will still break it though)

(IFS=$'\n'; vi $(locate php.ini))

Explanation:

What's happening is that programs inherit their file descriptors from the process that spawned them. xargs has its STDIN connected to the STDOUT of locate, so vi has no clue what the original STDIN really in.

Answer 3

With GNU findutils, and a shell with support for process substitution (ksh, zsh, bash), you can do:

xargs -r0a <(locate -0 php.ini) vi

The idea being to pass the file list via a -a filename rather than stdin. Using -0 makes sure it works regardless of what characters or non-characters the file names may contain.

With zsh, you could do:

vi ${(0)"$(locate -0 php.ini)"}

(where 0 is the parameter expansion flag to split on NULs).

However note that contrary to xargs -r that still runs vi without argument if no file is found.

Answer 4

This error happens when vim is invoked and it's connected to the previous pipeline's output, instead of the terminal and it's receiving different unexpected input (like NULs). The same happens when you run: vim < /dev/null, so reset command in this case helps. This is explained well by grawity at superuser.

On Unix/OSX you can use xargs with -o parameter, like:

locate php.ini | xargs -o vim

^{-o Reopen stdin as /dev/tty in the child process before executing the command. This is useful if you want xargs to run an interactive application.}

On Linux try the following workaround:

locate php.ini | xargs -J% sh -c 'vim < /dev/tty $@'

Alternatively use GNU parallel instead of xargs to force tty allocation, in example:

locate php.ini | parallel -X --tty vi

^{Note: parallelon Unix/OSX won't work as it has different parameters and it doesn't support tty.}

^{Many other popular commands provides pseudo-tty allocation as well (like -t in ssh), so check for help.}

Alternatively use find to pass file names to edit, so don't need xargs, just use -exec, in example:

find /etc -name php.ini -exec vim {} +

Answer 5

Edit multiple php.ini within the same editor ?

Try: vim -o $(locate php.ini)

Answer 6

@Patrick's IFS hack is only necessary for dumb shells like bash and zsh. fish splits the string on newlines by default.

$ vim (locate php.ini)

And God help us all if a single one of us actually has a file with a newline in its name. After 17 years using Linux, I haven't seen it even once. I'd only bother supporting filenames with newlines in them for scripts that have to work no matter what, but scripts like that probably aren't running vim interactively.

Answer 7

The "vi" way (vs the "ex way") is historically more like:

vi /tmp/$$.out
~
~
:r!locate php.ini

Instead of trying to pipe to vi from stdin or stdout (which is not normally supported outside of vim-alikes), you open vi and use ex Command mode to execute your "shell stuff". Then you can munge the results in-place.

This method should work in any proper ex implementation. vi is traditionally just a Visual Interface to ex.
Or putting it another way, ex -v is more commonly known / executed as "vi" for short.

You could even perform these kinds of operations with a macro (@) in Input mode and/or use undo to make changes and/or corrections.

The ex way

If you want to do it in a script then it could be with ex commands from a here-doc or something:

tmp=/tmp/$$.out
ex -s ${tmp} <<EOS
:r!locate php.ini
:wq
EOS
vi ${tmp}

You can use almost any combination of valid scripting / sh or ex commands with this method, such as the find suggestion from others.

Again, ex is POSIX, so it should work in GNU/Linux, *BSD, HP-UX, AIX, etc.

Variation

Presuming there are no security concerns, you might redirect to a file first then munge it separately, depending on your use case:

tmp=/tmp/$$.out
locate php.ini > ${tmp}
vi ${tmp}

However...

If just browsing is truly your goal then you may only need something like:

locate php.ini | more

I am throwing that out there because we can all over-complicate simple things at times.