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.

  • Same question on SU. – jw013 Jul 31 '12 at 21:00
  • 1
    As a side note, you can run reset to reset your terminal when it gets screwed up (you don't have to disconnect from ssh session). – wisbucky Nov 1 '18 at 22:17
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))


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.

  • 2
    xargs is wonderful, one of my favourite tools - it's just not suited for use with programs that use stdin for anything other than a data feed. i like your answer and your explanation other than that, so +1 anyway :) – cas Jul 31 '12 at 22:16
  • @CraigSanders I don't like it because it's too easy to abuse (use improperly) and end up breaking. I've never run into anything that I've absolutely had to use xargs for that couldn't be done directly with the shell (or find). However I can think of cases where it would be the best solution. So, so long as you understand what xargs is doing, how it splits up the arguments, how it runs the program, etc, and are using it properly, I'd say go for it :-P – phemmer Jul 31 '12 at 22:23
  • it can't be beat for things like ... | awk '{print $3}' | xargs | sed -e 's/ /+/g' | bc (to add up all the values of field 3). or with sed -e 's/ /|/g' to construct a regexp. and yes, like any tool, you do need to know how to use it and what its limitations and caveats are. – cas Jul 31 '12 at 22:29
  • The vi $(...) approach also has a problem with wildcards in shells other than zsh. – Stéphane Chazelas Jan 25 '20 at 18:30
  • Also note that with the xargs approach beside the whitespace issue, file names with single quotes, double quotes and backslashes are also a problem. – Stéphane Chazelas Jan 25 '20 at 20:08

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.

This is mentioned in the manual pages for xarg. From OSX/BSD:

-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 OSX, you could use the following command:

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

While, there is no direct switch on the GNU version, this 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.

  • 4
    +1 thanks for the -o tip. i've been using xargs for years and never noticed that....just checked the man page on my system, that's because it's not a GNU xargs feature. The man page does provide xargs sh -c 'emacs "$@" < /dev/tty' emacs as what they claim is a more flexible and portable alternative (although it's kind of funny for GNU to be prefer portability to features :). – cas Jul 31 '12 at 22:22
  • Without dummy string: '<dev/tty "$0" "$@"' vim – darw Oct 21 '20 at 12:41

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.


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 {} +
  • xargs -J is not available on GNU Linux. Can you give the output of bash -c 'echo $OSTYPE' (or zsh -c 'echo $OSTYPE') (or uname -o if available) on the system where you're able to use xargs -J ? – SebMa Oct 3 '20 at 0:18

Edit multiple php.ini within the same editor ?

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


@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.

  • zsh splits on SPC, TAB, NL and NUL by default. The thing it doesn't do compared to bash is perform globbing on the result so wildcard characters in file names are not a problem. In zsh, you'd do IFS=$'\0'; vi $(locate -0 php.ini) or as I shown in my answer vi ${(0)"$(locate -0 php.ini)"} for an explicit splitting operator. Also note tcsh's vi "`locate php.ini`" – Stéphane Chazelas Jan 25 '20 at 19:03
  • aw, crap. OK this works: $ f='not there'<ret>$ ls $f<ret> but this doesn't: ls echo not there. OK looks like I need to update this a bit. – enigmaticPhysicist Jan 29 '20 at 1:57
  • Yeah, zsh doesn't do the right thing when you do ls "$(echo test; echo other test)". Only fish does the right thing. – enigmaticPhysicist Jan 29 '20 at 2:04
  • Assuming you meant the same without the quotes, that's not "right", that's splitting on lines, it's just a different choice. zsh splits on words by default (like all other shells) and can be told to split on lines or on NULs, either via $IFS or via explicit operators (f and 0 parameter expansion flags). For arbitrary file names, splitting by word or splitting by line is equally wrong, you need to split on NUL or parse some encoding, which fish can't do. In zsh, that's IFS=$'\0'; ls -ld -- $(printf '%s\0' "$file1" "$file2") or ls -ld -- ${(0)"$(printf '%s\0' "$file1" "$file2")"} – Stéphane Chazelas Jan 29 '20 at 9:01
  • Meh. Splitting on newlines is good enough. Like the answer says, newlines in filenames are extremely rare. I have literally never seen it happen in 17 years. And newlines are way more convenient separators than nuls. – enigmaticPhysicist Jan 29 '20 at 21:44

A quick way to do it, assuming you can guarantee none of the file paths contain SPC, TAB, NL, *, ?, [ characters (also \ and {...} in some shells) is to use back-ticks (a.k.a. grave accents) to execute a command prior to another command running .


vi `find / -type f -name 'php.ini'`

The command contained within the back-ticks will execute first. The output of the contained command is then executed by the command stated before the back-ticks.

For example, in the line above, the find / -type f -name 'php.ini' command will execute first, send output, and then vi will be executed on the result of split+glob applied to that output.

  • 3
    back-ticks are too easily confused for single-quotes. use $(find ...) instead. – cas Jul 31 '12 at 22:24
  • 1
    guessing this will also break on spaces and/or newlines in the file names? – cwd Aug 1 '12 at 12:08
  • This is how you execute shell commands in bash scripting. I've never had anything break on spaces or new lines in my scripts or when using it in a one liner. However, I've never tried to open multiple files in vi using this method. It's quite possible it could break on new lines or spaces, depending on how vi is reading and executing the output. – tacotuesday Aug 8 '12 at 6:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.