xargs and vi - “Input is not from a terminal”

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP











up vote
11
down vote

favorite
2












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.










share|improve this question





















  • Same question on SU.
    – jw013
    Jul 31 '12 at 21:00










  • 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
    yesterday














up vote
11
down vote

favorite
2












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.










share|improve this question





















  • Same question on SU.
    – jw013
    Jul 31 '12 at 21:00










  • 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
    yesterday












up vote
11
down vote

favorite
2









up vote
11
down vote

favorite
2






2





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.










share|improve this 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.







command-line terminal vi xargs






share|improve this question













share|improve this question











share|improve this question




share|improve this question










asked Jul 31 '12 at 20:52









cwd

13.1k52114156




13.1k52114156











  • Same question on SU.
    – jw013
    Jul 31 '12 at 21:00










  • 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
    yesterday
















  • Same question on SU.
    – jw013
    Jul 31 '12 at 21:00










  • 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
    yesterday















Same question on SU.
– jw013
Jul 31 '12 at 21:00




Same question on SU.
– jw013
Jul 31 '12 at 21:00












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
yesterday




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
yesterday










5 Answers
5






active

oldest

votes

















up vote
10
down vote



accepted










I hate xargs, I really wish it'd just die :-)



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.






share|improve this answer


















  • 1




    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
    – Patrick
    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


















up vote
7
down vote













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.






share|improve this answer


















  • 2




    +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

















up vote
1
down vote













A quick way to do it is to use back-ticks (a.k.a. grave accents) to execute a command prior to another command running .



E.g.



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 that output.






share|improve this answer
















  • 1




    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.
    – nojak
    Aug 8 '12 at 6:07


















up vote
1
down vote













Edit multiple php.ini within the same editor ?



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






share|improve this answer



























    up vote
    0
    down vote













    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 +





    share|improve this answer






















      Your Answer








      StackExchange.ready(function()
      var channelOptions =
      tags: "".split(" "),
      id: "106"
      ;
      initTagRenderer("".split(" "), "".split(" "), channelOptions);

      StackExchange.using("externalEditor", function()
      // Have to fire editor after snippets, if snippets enabled
      if (StackExchange.settings.snippets.snippetsEnabled)
      StackExchange.using("snippets", function()
      createEditor();
      );

      else
      createEditor();

      );

      function createEditor()
      StackExchange.prepareEditor(
      heartbeatType: 'answer',
      convertImagesToLinks: false,
      noModals: true,
      showLowRepImageUploadWarning: true,
      reputationToPostImages: null,
      bindNavPrevention: true,
      postfix: "",
      imageUploader:
      brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
      contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
      allowUrls: true
      ,
      onDemand: true,
      discardSelector: ".discard-answer"
      ,immediatelyShowMarkdownHelp:true
      );



      );













       

      draft saved


      draft discarded


















      StackExchange.ready(
      function ()
      StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f44426%2fxargs-and-vi-input-is-not-from-a-terminal%23new-answer', 'question_page');

      );

      Post as a guest






























      5 Answers
      5






      active

      oldest

      votes








      5 Answers
      5






      active

      oldest

      votes









      active

      oldest

      votes






      active

      oldest

      votes








      up vote
      10
      down vote



      accepted










      I hate xargs, I really wish it'd just die :-)



      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.






      share|improve this answer


















      • 1




        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
        – Patrick
        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















      up vote
      10
      down vote



      accepted










      I hate xargs, I really wish it'd just die :-)



      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.






      share|improve this answer


















      • 1




        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
        – Patrick
        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













      up vote
      10
      down vote



      accepted







      up vote
      10
      down vote



      accepted






      I hate xargs, I really wish it'd just die :-)



      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.






      share|improve this answer














      I hate xargs, I really wish it'd just die :-)



      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.







      share|improve this answer














      share|improve this answer



      share|improve this answer








      edited Jul 31 '12 at 21:24

























      answered Jul 31 '12 at 21:10









      Patrick

      48.9k11126177




      48.9k11126177







      • 1




        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
        – Patrick
        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













      • 1




        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
        – Patrick
        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








      1




      1




      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





      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
      – Patrick
      Jul 31 '12 at 22:23




      @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
      – Patrick
      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





      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













      up vote
      7
      down vote













      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.






      share|improve this answer


















      • 2




        +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














      up vote
      7
      down vote













      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.






      share|improve this answer


















      • 2




        +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












      up vote
      7
      down vote










      up vote
      7
      down vote









      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.






      share|improve this answer














      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.







      share|improve this answer














      share|improve this answer



      share|improve this answer








      edited 10 mins ago









      wisbucky

      468610




      468610










      answered Jul 31 '12 at 21:20









      darnir

      3,19711226




      3,19711226







      • 2




        +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












      • 2




        +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







      2




      2




      +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




      +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










      up vote
      1
      down vote













      A quick way to do it is to use back-ticks (a.k.a. grave accents) to execute a command prior to another command running .



      E.g.



      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 that output.






      share|improve this answer
















      • 1




        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.
        – nojak
        Aug 8 '12 at 6:07















      up vote
      1
      down vote













      A quick way to do it is to use back-ticks (a.k.a. grave accents) to execute a command prior to another command running .



      E.g.



      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 that output.






      share|improve this answer
















      • 1




        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.
        – nojak
        Aug 8 '12 at 6:07













      up vote
      1
      down vote










      up vote
      1
      down vote









      A quick way to do it is to use back-ticks (a.k.a. grave accents) to execute a command prior to another command running .



      E.g.



      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 that output.






      share|improve this answer












      A quick way to do it is to use back-ticks (a.k.a. grave accents) to execute a command prior to another command running .



      E.g.



      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 that output.







      share|improve this answer












      share|improve this answer



      share|improve this answer










      answered Jul 31 '12 at 21:37









      nojak

      34414




      34414







      • 1




        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.
        – nojak
        Aug 8 '12 at 6:07













      • 1




        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.
        – nojak
        Aug 8 '12 at 6:07








      1




      1




      back-ticks are too easily confused for single-quotes. use $(find ...) instead.
      – cas
      Jul 31 '12 at 22:24




      back-ticks are too easily confused for single-quotes. use $(find ...) instead.
      – cas
      Jul 31 '12 at 22:24




      1




      1




      guessing this will also break on spaces and/or newlines in the file names?
      – cwd
      Aug 1 '12 at 12:08




      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.
      – nojak
      Aug 8 '12 at 6:07





      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.
      – nojak
      Aug 8 '12 at 6:07











      up vote
      1
      down vote













      Edit multiple php.ini within the same editor ?



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






      share|improve this answer
























        up vote
        1
        down vote













        Edit multiple php.ini within the same editor ?



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






        share|improve this answer






















          up vote
          1
          down vote










          up vote
          1
          down vote









          Edit multiple php.ini within the same editor ?



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






          share|improve this answer












          Edit multiple php.ini within the same editor ?



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







          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered Aug 1 '12 at 8:04









          daisy

          28k46165297




          28k46165297




















              up vote
              0
              down vote













              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 +





              share|improve this answer


























                up vote
                0
                down vote













                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 +





                share|improve this answer
























                  up vote
                  0
                  down vote










                  up vote
                  0
                  down vote









                  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 +





                  share|improve this answer














                  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 +






                  share|improve this answer














                  share|improve this answer



                  share|improve this answer








                  edited Mar 20 '17 at 10:18









                  Community♦

                  1




                  1










                  answered Feb 18 '15 at 12:59









                  kenorb

                  7,951365105




                  7,951365105



























                       

                      draft saved


                      draft discarded















































                       


                      draft saved


                      draft discarded














                      StackExchange.ready(
                      function ()
                      StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f44426%2fxargs-and-vi-input-is-not-from-a-terminal%23new-answer', 'question_page');

                      );

                      Post as a guest













































































                      Popular posts from this blog

                      How to check contact read email or not when send email to Individual?

                      Bahrain

                      Postfix configuration issue with fips on centos 7; mailgun relay