xargs and vi - âInput is not from a terminalâ
Clash Royale CLAN TAG#URR8PPP
up vote
11
down vote
favorite
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
add a comment |Â
up vote
11
down vote
favorite
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
Same question on SU.
â jw013
Jul 31 '12 at 21:00
As a side note, you can runreset
to reset your terminal when it gets screwed up (you don't have to disconnect from ssh session).
â wisbucky
yesterday
add a comment |Â
up vote
11
down vote
favorite
up vote
11
down vote
favorite
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
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
command-line terminal vi xargs
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 runreset
to reset your terminal when it gets screwed up (you don't have to disconnect from ssh session).
â wisbucky
yesterday
add a comment |Â
Same question on SU.
â jw013
Jul 31 '12 at 21:00
As a side note, you can runreset
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
add a comment |Â
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.
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 usexargs
for that couldn't be done directly with the shell (orfind
). However I can think of cases where it would be the best solution. So, so long as you understand whatxargs
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 withsed -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
add a comment |Â
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.
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 providexargs 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
add a comment |Â
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.
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 invi
using this method. It's quite possible it could break on new lines or spaces, depending on howvi
is reading and executing the output.
â nojak
Aug 8 '12 at 6:07
add a comment |Â
up vote
1
down vote
Edit multiple php.ini within the same editor ?
Try: vim -o $(locate php.ini)
add a comment |Â
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: parallel
on 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 +
add a comment |Â
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.
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 usexargs
for that couldn't be done directly with the shell (orfind
). However I can think of cases where it would be the best solution. So, so long as you understand whatxargs
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 withsed -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
add a comment |Â
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.
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 usexargs
for that couldn't be done directly with the shell (orfind
). However I can think of cases where it would be the best solution. So, so long as you understand whatxargs
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 withsed -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
add a comment |Â
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.
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.
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 usexargs
for that couldn't be done directly with the shell (orfind
). However I can think of cases where it would be the best solution. So, so long as you understand whatxargs
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 withsed -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
add a comment |Â
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 usexargs
for that couldn't be done directly with the shell (orfind
). However I can think of cases where it would be the best solution. So, so long as you understand whatxargs
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 withsed -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
add a comment |Â
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.
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 providexargs 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
add a comment |Â
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.
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 providexargs 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
add a comment |Â
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.
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.
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 providexargs 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
add a comment |Â
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 providexargs 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
add a comment |Â
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.
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 invi
using this method. It's quite possible it could break on new lines or spaces, depending on howvi
is reading and executing the output.
â nojak
Aug 8 '12 at 6:07
add a comment |Â
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.
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 invi
using this method. It's quite possible it could break on new lines or spaces, depending on howvi
is reading and executing the output.
â nojak
Aug 8 '12 at 6:07
add a comment |Â
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.
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.
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 invi
using this method. It's quite possible it could break on new lines or spaces, depending on howvi
is reading and executing the output.
â nojak
Aug 8 '12 at 6:07
add a comment |Â
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 invi
using this method. It's quite possible it could break on new lines or spaces, depending on howvi
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
add a comment |Â
up vote
1
down vote
Edit multiple php.ini within the same editor ?
Try: vim -o $(locate php.ini)
add a comment |Â
up vote
1
down vote
Edit multiple php.ini within the same editor ?
Try: vim -o $(locate php.ini)
add a comment |Â
up vote
1
down vote
up vote
1
down vote
Edit multiple php.ini within the same editor ?
Try: vim -o $(locate php.ini)
Edit multiple php.ini within the same editor ?
Try: vim -o $(locate php.ini)
answered Aug 1 '12 at 8:04
daisy
28k46165297
28k46165297
add a comment |Â
add a comment |Â
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: parallel
on 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 +
add a comment |Â
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: parallel
on 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 +
add a comment |Â
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: parallel
on 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 +
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: parallel
on 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 +
edited Mar 20 '17 at 10:18
Communityâ¦
1
1
answered Feb 18 '15 at 12:59
kenorb
7,951365105
7,951365105
add a comment |Â
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
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
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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