Using terminal output as input
Dotan Cohen
output of one terminal command as the input for another. A classic
example is the which command:
$ which firefox
/usr/bin/firefox
$
Now, I would like to use that output as input, to start firefox. Other
than manually typing it in, is there a way for the user to use the
output directly?
Another example is when the OS lets the user know that she needs to
install a program and gives her the command to install it:
$ ekiga
The program 'ekiga' is currently not installed. You can install it by typing:
sudo apt-get install ekiga
bash: ekiga: command not found
$
In contrast to the "which" example, the text that the user needs is
buried in the output. Is there a way to use it anyway, without
retyping (and without using the mouse, which I often do not have).
Thanks!
--
Dotan Cohen
http://what-is-what.com
http://gibberish.co.il
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Dotan Cohen
> `which firefox`
> the above command will fire the firefox command
Thanks, Bhasker. I meant to ask, in the more general sense, how to use
the terminal output as input. The second example in the OP describes
that more.
S Scharf
I am using a Debian-based distro (Ubuntu). Often I need to use the
output of one terminal command as the input for another. A classic
example is the which command:
$ which firefox
/usr/bin/firefox
$
Now, I would like to use that output as input, to start firefox. Other
than manually typing it in, is there a way for the user to use the
output directly?
Another example is when the OS lets the user know that she needs to
install a program and gives her the command to install it:
$ ekiga
The program 'ekiga' is currently not installed. You can install it by typing:
sudo apt-get install ekiga
bash: ekiga: command not found
$
Not pretty but how about
`ekiga | head -2 | tail -1`
(note use of backticks)
Stuart
Bhasker C V
> I am using a Debian-based distro (Ubuntu). Often I need to use the
> output of one terminal command as the input for another. A classic
> example is the which command:
> $ which firefox
> /usr/bin/firefox
> $
do you mean using the back-quote
`which firefox`
the above command will fire the firefox command
>
> Now, I would like to use that output as input, to start firefox. Other
> than manually typing it in, is there a way for the user to use the
> output directly?
>
> Another example is when the OS lets the user know that she needs to
> install a program and gives her the command to install it:
> $ ekiga
> The program 'ekiga' is currently not installed. You can install it by typing:
> sudo apt-get install ekiga
> bash: ekiga: command not found
> $
>
> In contrast to the "which" example, the text that the user needs is
> buried in the output. Is there a way to use it anyway, without
> retyping (and without using the mouse, which I often do not have).
> Thanks!
>
> --
> Dotan Cohen
>
> http://what-is-what.com
> http://gibberish.co.il
>
>
> --
> To UNSUBSCRIBE, email to debian-us...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
>
Bhasker C V
Registered linux user #306349
Roger Leigh
> On Thu, May 14, 2009 at 10:55 AM, Dotan Cohen <dotan...@gmail.com> wrote:
>
> > I am using a Debian-based distro (Ubuntu). Often I need to use the
> > output of one terminal command as the input for another. A classic
> > example is the which command:
> > $ which firefox
> > /usr/bin/firefox
> > $
> >
> > Now, I would like to use that output as input, to start firefox. Other
> > than manually typing it in, is there a way for the user to use the
> > output directly?
> >
> > Another example is when the OS lets the user know that she needs to
> > install a program and gives her the command to install it:
> > $ ekiga
> > The program 'ekiga' is currently not installed. You can install it by
> > typing:
> > sudo apt-get install ekiga
> > bash: ekiga: command not found
> > $
>
>
> Not pretty but how about
> `ekiga | head -2 | tail -1`
Also note that
$(ekiga | head -2 | tail -1)
is a more portable equivalent. $() is the same as `` but unlike `` can
be nested, and has less quoting issues. You can enclose it in
double quotes, for example since it behaves like a variable expansion.
Regards,
Roger
--
.''`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/
`- GPG Public Key: 0x25BFB848 Please GPG sign your mail.
Dotan Cohen
>
> $(ekiga | head -2 | tail -1)
>
> is a more portable equivalent. $() is the same as `` but unlike `` can
> be nested, and has less quoting issues. You can enclose it in
> double quotes, for example since it behaves like a variable expansion.
>
That also does not work on Debian-derived Ubuntu, so I do not know how
portable that is! But thanks for the tip, I certainly did learn
something and that's most important.
--
Dotan Cohen
http://what-is-what.com
http://gibberish.co.il
Dotan Cohen
> `ekiga | head -2 | tail -1`
>
> (note use of backticks)
>
That's creative! It doesn't seem to work on this system, I will try on
Real Debian (tm) when I get home. However, it does require
foreknowledge of the output, which I suppose is all right if the user
can run the same command again.
I just thought that there would be a command made for this, as it
seems to be a common situation. I did not think that it would have to
resort to hacks.
Harry Rickards
Hash: SHA1
On 05/14/09 15:55, Dotan Cohen wrote:
> I am using a Debian-based distro (Ubuntu). Often I need to use the
> output of one terminal command as the input for another. A classic
> example is the which command:
> $ which firefox
> /usr/bin/firefox
> $
>
> Now, I would like to use that output as input, to start firefox. Other
> than manually typing it in, is there a way for the user to use the
> output directly?
As well as all the other answers, you could pipe the output to bash.
This will work with any command where the command you want to run is the
only output displayed.
$ which firefox | bash
> Another example is when the OS lets the user know that she needs to
> install a program and gives her the command to install it:
> $ ekiga
> The program 'ekiga' is currently not installed. You can install it by typing:
> sudo apt-get install ekiga
> bash: ekiga: command not found
> $
>
> In contrast to the "which" example, the text that the user needs is
> buried in the output. Is there a way to use it anyway, without
> retyping (and without using the mouse, which I often do not have).
> Thanks!
>
- --
Many thanks
Harry Rickards
- -----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GAT/GCM/GCS/GCC/GIT/GM d? s: a? C++++ UL++++ P- L+++ E--- W+++ N o K+
w--- O- M- V- PS+ PE Y+ PGP++ t 5 X R tv-- b+++ DI D---- G e* h! !r y?
- ------END GEEK CODE BLOCK------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkoMO9EACgkQ1kZz3mRu0GrfKwCfS7dYeOjRBNErbbgKDBFinLwe
IYwAoJguSFX/h5ZJzE5mWDIs2OfQVWqu
=UDyI
-----END PGP SIGNATURE-----
Eduardo M KALINOWSKI
>> Not pretty but how about
>> `ekiga | head -2 | tail -1`
>>
>> (note use of backticks)
>>
>>
>
> That's creative! It doesn't seem to work on this system, I will try on
> Real Debian (tm) when I get home. However, it does require
> foreknowledge of the output, which I suppose is all right if the user
> can run the same command again.
>
> I just thought that there would be a command made for this, as it
> seems to be a common situation. I did not think that it would have to
> resort to hacks.
>
Like you said, it does require foreknowledge of the output. So there is
no way to make a one-size-fits-all solution, be it a command-line trick
or a program.
If you told us exactly what you want to achieve, we might be able to
help you better.
--
Every cloud engenders not a storm.
-- William Shakespeare, "Henry VI"
Eduardo M KALINOWSKI
edu...@kalinowski.com.br
Boyd Stephen Smith Jr.
wrote:
>I am using a Debian-based distro (Ubuntu). Often I need to use the
>output of one terminal command as the input for another.
UNIX-ish OSes and programs are designed for this, but you'll have to learn
the small tools in order to build the custom tools you want.
In general, terminal commands read from "standard input" and write to
"standard output" and "standard error". These names are often shorted:
standard input = stdin = file descriptor 0 = fd 0
standard output = stdout = file descriptor 1 = fd 1
standard error = stderr = file descriptor 2 = fd 2
By default, all of these are attached to your terminal. However, you can
use redirection and pipes to have a terminal command read or write to other
files or other commands.
"> file" makes a command's standard output write to a new, empty file.
">> file" makes a command's standard output append to an existing file.
"< file" makes a command's standard input read from an existing file.
"cmd1 | cmd2" makes cmd1's standard output write cmd2's standard input.
"$(cmd1)" captures a command's standard output (removing the last '\n' if
there is one) and uses it as part of the shell's input -- similar to a
variable expansion.
info:/bash/Redirections and info:/bash/Pipelines has more details.
http://www.opengroup.org/onlinepubs/000095399/utilities/xcu_chap02.html is
the canonical reference, but it is dry, technical, and probably has a lot
more details that you are not interested in immediately. The link also may
require registration.
These are particularly useful when combined with the "UNIX filter commands"
tr, grep, sed, cut, paste, and awk plus the tee command.
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
b...@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/ \_/
Ken Irving
> I am using a Debian-based distro (Ubuntu). Often I need to use the
> output of one terminal command as the input for another. A classic
> example is the which command:
> $ which firefox
> /usr/bin/firefox
> $
>
> Now, I would like to use that output as input, to start firefox. Other
> than manually typing it in, is there a way for the user to use the
> output directly?
>
> Another example is when the OS lets the user know that she needs to
> install a program and gives her the command to install it:
> $ ekiga
> The program 'ekiga' is currently not installed. You can install it by typing:
> sudo apt-get install ekiga
> bash: ekiga: command not found
> $
>
> In contrast to the "which" example, the text that the user needs is
> buried in the output. Is there a way to use it anyway, without
> retyping (and without using the mouse, which I often do not have).
> Thanks!
I'm not sure, but you may be seeing the 'command-not-found' hook that was
added to bash 3.x as a patch in debian and ubuntu, and I think programmed
in ubuntu to install the program (or maybe just to suggest doing that,
as in your example). This scheme was accepted into bash 4.0 with some
improvements, e.g., giving access to the failed command's argument list,
vs the older patch which only kept the command itself.
(If you're interested, you could check for a function called
command_not_found_handler() or similar in your shell environment, and
just see what it contains. That function could be redefined for other
purposes, but, again, it only provides access to the command, not to
the arguments (unless that's been fixed since I've looked.)
I'm not sure how that relates to the subject question. These things
differ according to what shell you're using, but in bash `backticks` are
the "old" way of treating shell output as input, and the $(...) construct
is the "new" way.
You might try something like this, which works for me on bash in lenny:
$ exec $(which iceweasel)
If you don't use exec the process will run as a child process of the
shell, while exec replaces the shell with the new process.
Ken
--
Ken Irving
S Scharf
> Not pretty but how aboutThat's creative! It doesn't seem to work on this system, I will try on
> `ekiga | head -2 | tail -1`
>
> (note use of backticks)
>
Real Debian (tm) when I get home. However, it does require
foreknowledge of the output, which I suppose is all right if the user
can run the same command again.
Oops, the output of ekiga is going to stderr and not stdout. Only stdout gets piped.
Anyone know how to capture and pipe stdout?
Stuart
S Scharf
On Thu, May 14, 2009 at 11:13 AM, Dotan Cohen <dotan...@gmail.com> wrote:> Not pretty but how aboutThat's creative! It doesn't seem to work on this system, I will try on
> `ekiga | head -2 | tail -1`
>
> (note use of backticks)
>
Real Debian (tm) when I get home. However, it does require
foreknowledge of the output, which I suppose is all right if the user
can run the same command again.
Oops, the output of ekiga is going to stderr and not stdout. Only stdout gets piped.
Anyone know how to capture and pipe stdout?
to answer my own question try this:
$(ekiga 2>/dev/stdout | head -2 | tail -1)
Stuart
Boyd Stephen Smith Jr.
wrote:
>$(ekiga 2>/dev/stdout | head -2 | tail -1)
More portable, but the same results:
$(ekiga 2>&1 | head -n 2 | tail -n 1)
tyler
> I am using a Debian-based distro (Ubuntu). Often I need to use the
> output of one terminal command as the input for another. A classic
> example is the which command:
> $ which firefox
> /usr/bin/firefox
> $
This may be a stupid question, but what's the difference between firefox
and $(which firefox)? They both run the first executable named firefox
in your path, don't they?
Tyler
--
What is wanted is not the will to believe, but the will to find out,
which is the exact opposite. --Bertrand Russell
PaulNM
Dotan Cohen <dotan...@gmail.com> writes: > I am using a Debian-based distro (Ubuntu). Often I need to use the > output of one terminal command as the input for another. A classic > example is the which command: > $ which firefox > /usr/bin/firefox > $ This may be a stupid question, but what's the difference between firefox and $(which firefox)? They both run the first executable named firefox in your path, don't they? Tyler -- What is wanted is not the will to believe, but the will to find out, which is the exact opposite. --Bertrand Russell
For example:
$ which test
/usr/bin/test
But if you actually run test (in bash at least), it's the shell's built in version, not /usr/bin/test.
PaulNM
S Scharf
shell mode of 'emacs'.
Stuart
Frank Lin PIAT
>
> On Thu, May 14, 2009 at 11:13 AM, Dotan Cohen <dotan...@gmail.com>
> wrote:
> > Not pretty but how about
> > `ekiga | head -2 | tail -1`
> >
> > (note use of backticks)
> >
>
>
> That's creative! It doesn't seem to work on this system, I
> will try on
> Real Debian (tm) when I get home. However, it does require
> foreknowledge of the output, which I suppose is all right if
> the user
> can run the same command again.
>
> Oops, the output of ekiga is going to stderr and not stdout. Only
> stdout gets piped.
>
> Anyone know how to capture and pipe stdout?
I am not sure that's something I would do... but here it is:
$`ekiga 2>&1 | sed -n 2p`
Where you tell sed:
"-n" => Don't print the lines by default.
"2p" => When you match the line Number 2, then _p_rint it.
(BTW, the dollar sign is the prompt, not something to type)
Alternatively, this one could be an option because your are prompted
before running the command:
$ekiga 2>&1 | xargs -n 1 -p sh -c
Obviously, it becomes much more sexy if you create an alias:
$alias Qrun='xargs -n 1 -p sh -c'
So just type:
$ekiga 2>&1 | Qrun
sh -c The program 'ekiga' is currently not installed. You can install
it by typing: ?...n
sh -c sudo apt-get install ekiga ?...y
And here you go !
Regards,
Franklin
P.S. All that is completely untested ;)
Tzafrir Cohen
> output of one terminal command as the input for another. A classic
> example is the which command:
> $ which firefox
> /usr/bin/firefox
Use a terminal that supports it.
screen is one such terminal. Emacs is another.
Alternatively, running the command under script(1) sends all the text
(though with annoying special characters) to a file as well.
--
Tzafrir Cohen | tza...@jabber.org | VIM is
http://tzafrir.org.il | | a Mutt's
tza...@cohens.org.il | | best
ICQ# 16849754 | | friend
Chris Jones
> I am using a Debian-based distro (Ubuntu). Often I need to use the
> output of one terminal command as the input for another. A classic
> example is the which command:
> $ which firefox
> /usr/bin/firefox
> $
>
> Now, I would like to use that output as input, to start firefox. Other
> than manually typing it in, is there a way for the user to use the
> output directly?
>
> Another example is when the OS lets the user know that she needs to
> install a program and gives her the command to install it:
> $ ekiga
> The program 'ekiga' is currently not installed. You can install it by typing:
> sudo apt-get install ekiga
> bash: ekiga: command not found
> $
Off-hand, the only thing that comes to mind is using "history -s" to add
the command's output to the bash session's history list so that you can
retrieve it via Ctrl-P (or up-arrow) and use the readline editor to
"extract" the actual command:
$ history -s $(ekiga)
To make things a bit more useable, maybe there's a way to bind a key
combo to a bash function that would do the above for _any_ command:
$ ekiga + Ctrl-whatever
.. would execute:
$ add-output-to-history ekiga
With the bash function coded something like:
add-output-to-history () {history -s $($*)} # UNTESTED !!
Since this ugly hack would seriously pollute the bash session's history
list, you would need to write a program/script that runs automaticaly
when exiting the bash session and removes all the crap before it gets
appended to the ~/.bash_history file.
> In contrast to the "which" example, the text that the user needs is
> buried in the output. Is there a way to use it anyway, without
> retyping (and without using the mouse, which I often do not have).
For stuff like that where the output is totally unpredictable, I doubt
anything beats the flexibility of gnu/screen's copy/paste mechanism.
:-)
CJ
Dotan Cohen
> no way to make a one-size-fits-all solution, be it a command-line trick
> or a program.
>
> If you told us exactly what you want to achieve, we might be able to
> help you better.
>
I just want to know in a very general sense how to use the output of
commands without typing them in manually. It seemed to me that as *nix
was developed for the CLI interface (with GUIs coming around only
years later) that this would be possible.
I do not have a specific task at hand.
--
Dotan Cohen
http://what-is-what.com
http://gibberish.co.il
Dotan Cohen
> In <880dece00905140755w67...@mail.gmail.com>, Dotan Cohen
> wrote:
>>I am using a Debian-based distro (Ubuntu). Often I need to use the
>>output of one terminal command as the input for another.
>
> UNIX-ish OSes and programs are designed for this, but you'll have to learn
> the small tools in order to build the custom tools you want.
>
> In general, terminal commands read from "standard input" and write to
> "standard output" and "standard error". These names are often shorted:
> standard input = stdin = file descriptor 0 = fd 0
> standard output = stdout = file descriptor 1 = fd 1
> standard error = stderr = file descriptor 2 = fd 2
>
> By default, all of these are attached to your terminal. However, you can
> use redirection and pipes to have a terminal command read or write to other
> files or other commands.
>
> "> file" makes a command's standard output write to a new, empty file.
> ">> file" makes a command's standard output append to an existing file.
> "< file" makes a command's standard input read from an existing file.
> "cmd1 | cmd2" makes cmd1's standard output write cmd2's standard input.
>
> "$(cmd1)" captures a command's standard output (removing the last '\n' if
> there is one) and uses it as part of the shell's input -- similar to a
> variable expansion.
>
> info:/bash/Redirections and info:/bash/Pipelines has more details.
>
Thanks. This is pretty much what I knew, but stated better than I understood.
> http://www.opengroup.org/onlinepubs/000095399/utilities/xcu_chap02.html is
> the canonical reference, but it is dry, technical, and probably has a lot
> more details that you are not interested in immediately. The link also may
> require registration.
>
No registration needed, but it is a difficult read.
> These are particularly useful when combined with the "UNIX filter commands"
> tr, grep, sed, cut, paste, and awk plus the tee command.
I am baffled that one must type in the output to commands. For
instance, the sysadmin may need to use the existing DHCP IP address
for one reason or another. After running ifconfig, where the address
is stated, why must he type it in? I'm not looking for copy-paste in
the GUI sense, but some sort of this-to-there method for carrying
small bits of data seems so useful, basic, and would help prevent
typos.
Dotan Cohen
> anything beats the flexibility of gnu/screen's copy/paste mechanism.
>
This seems to be the key that I was looking for! I will look into
gnu/screen's copy/paste mechanism. Thanks.
--
Dotan Cohen
http://what-is-what.com
http://gibberish.co.il
Eduardo M KALINOWSKI
> I am baffled that one must type in the output to commands. For
> instance, the sysadmin may need to use the existing DHCP IP address
> for one reason or another. After running ifconfig, where the address
> is stated, why must he type it in? I'm not looking for copy-paste in
> the GUI sense, but some sort of this-to-there method for carrying
> small bits of data seems so useful, basic, and would help prevent
> typos.
>
As other people have pointed out, the way to capture a command's output
is with $(command) (or `command`, though this is a bashism). However,
unless the output is exactly in the form you need (which is often not
the case; in your example ifconfig outputs a lot of information besides
the IP address), the time it takes to come out with a command line that
filters only the part you need (using tools such as head, tail, cut,
etc.) is probably much greater than the time needed to type the
information again --- or cut and paste, if this is something you'll only
do a couple of times.
--
Your supervisor is thinking about you.
Eduardo M KALINOWSKI
edu...@kalinowski.com.br
Tzafrir Cohen
> As other people have pointed out, the way to capture a command's output
> is with $(command) (or `command`, though this is a bashism).
$(command) is bashism. `command` is the "pure" bourne shell form.
$ posh
$ echo `echo hi`
hi
$ echo $(echo hi)
hi
And likewise on dash and busybox ash, which are the other shells I have
here. IIRC latest posix includes $(command) as well.
--
Tzafrir Cohen | tza...@jabber.org | VIM is
http://tzafrir.org.il | | a Mutt's
tza...@cohens.org.il | | best
ICQ# 16849754 | | friend
Dotan Cohen
> is with $(command) (or `command`, though this is a bashism). However,
> unless the output is exactly in the form you need (which is often not
> the case; in your example ifconfig outputs a lot of information besides
> the IP address), the time it takes to come out with a command line that
> filters only the part you need (using tools such as head, tail, cut,
> etc.) is probably much greater than the time needed to type the
> information again --- or cut and paste, if this is something you'll only
> do a couple of times.
>
Yes, it seems that what I am looking for is copy-paste. I have seen it
suggested that screen can do this, though I have not yet looked into
it in detail.
--
Dotan Cohen
http://what-is-what.com
http://gibberish.co.il
John Hasler
> Yes, it seems that what I am looking for is copy-paste. I have seen it
> suggested that screen can do this, though I have not yet looked into it
> in detail.
The Linux console can do it with gpm.
--
John Hasler
Roger Leigh
> On Sun, May 17, 2009 at 08:51:38AM -0300, Eduardo M KALINOWSKI wrote:
>
> > As other people have pointed out, the way to capture a command's output
> > is with $(command) (or `command`, though this is a bashism).
>
> $(command) is bashism. `command` is the "pure" bourne shell form.
>
> here. IIRC latest posix includes $(command) as well.
It is definitely *not* a bashism, given that it is supported by POSIX.
It is supported by all POSIX shells, and this does include dash.
You should definitely use $() in place of backticks where possible, and
portability concerns are unwarranted here given that all real shells
include support for it. posh is an exception, but is not a POSIX shell
since it does not support this POSIX feature.
Regards,
Roger
--
.''`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/
`- GPG Public Key: 0x25BFB848 Please GPG sign your mail.
Boyd Stephen Smith Jr.
>> commands" tr, grep, sed, cut, paste, and awk plus the tee command.
>
>I am baffled that one must type in the output to commands. For
>instance, the sysadmin may need to use the existing DHCP IP address
>for one reason or another. After running ifconfig, where the address
>is stated, why must he type it in? I'm not looking for copy-paste in
>the GUI sense, but some sort of this-to-there method for carrying
>small bits of data seems so useful, basic, and would help prevent
>typos.
Something like this?:
$ /sbin/ifconfig wlan0 | awk -F'[: ]*' '/inet[^6]/ { print $4 }'
10.0.0.101
awk, sed, grep, etc. are how you filter the output down to exactly what you
need via pipes. Pipes or variables are how to get information into the
commands that could use it as input.
Your this-is-there method is the use of awk, grep, sed, etc.
Boyd Stephen Smith Jr.
>(or `command`, though this is a bashism)
Not a bash-ism. It is the older method and still required in SUS-conformant
shells. However, it doesn't nest well and has other issues that are
required not to affect $().
Barclay, Daniel
Dotan Cohen wrote:
>> Like you said, it does require foreknowledge of the output. So there is
>> no way to make a one-size-fits-all solution, be it a command-line trick
>> or a program.
>>
>> If you told us exactly what you want to achieve, we might be able to
>> help you better.
>>
>
> I just want to know in a very general sense how to use the output of
> commands without typing them in manually. It seemed to me that as *nix
> was developed for the CLI interface (with GUIs coming around only
> years later) that this would be possible.
>
> I do not have a specific task at hand.
You haven't resolved one particular bit of ambiguity in your question:
Are you asking about manually selecting part of the output of a command(s)
and using it to assemble another command (as opposed to piping the whole
output from one command into another)?
If so, another possible answer for you is gpm. (On a virtual console,
lets you select and copy text and paste it into the command line being
assembled (or into whatever process is reading from your virtual console)
using the mouse.)
Daniel
--
(Plain text sometimes corrupted to HTML "courtesy" of Microsoft Exchange.) [F]
Chris Jones
> Dotan Cohen wrote:
> >> If you told us exactly what you want to achieve, we might be able
> >> to help you better.
The OP did say exactly what he wants - that the output of one command
should be made available to the user so that he can edit it before
feeding it back to the shell.
> > I just want to know in a very general sense how to use the output of
> > commands without typing them in manually. It seemed to me that as
> > *nix was developed for the CLI interface (with GUIs coming around
> > only years later) that this would be possible.
> >
> > I do not have a specific task at hand.
> You haven't resolved one particular bit of ambiguity in your question:
My understanding is that he is talking about something that amounts to
an "interactive pipe" where the output of a program is made available to
the user in an editable buffer that he can play with before feeding back
to another program's input.
> Are you asking about manually selecting part of the output of a
> command(s) and using it to assemble another command (as opposed to
> piping the whole output from one command into another)?
That's pretty much how I understood it, although I disagree with the "as
opposed to".. I don't see an "opposition"... more of an extension to the
traditional pipe.
Not sure whether it's feasible - *nix utilities were designed around the
traditional pipe model where the _raw_ output of a program, not its
printed translation is fed to another program, or even whether it is
desirable..
> If so, another possible answer for you is gpm. (On a virtual console,
> lets you select and copy text and paste it into the command line being
> assembled (or into whatever process is reading from your virtual
> console) using the mouse.)
I also suggested the copying/pasting approach via gnu/screen's mechanism
but that's not really what the OP was asking and maybe there should be a
smarter alternative..??
CJ
Dotan Cohen
> but that's not really what the OP was asking and maybe there should be a
> smarter alternative..??
>
Actually, it seems that copy-paste is in fact what I am looking for. I
just figured that this would be common enough to be a part of the
shell itself, not something that would require workarounds or hacks. I
intend to learn screen.
--
Dotan Cohen
http://what-is-what.com
http://gibberish.co.il
Barclay, Daniel
Chris Jones wrote:
> On Mon, May 18, 2009 at 04:13:16PM EDT, Barclay, Daniel wrote:
>> Dotan Cohen wrote:
>
...
>
>> Are you asking about manually selecting part of the output of a
>> command(s) and using it to assemble another command (as opposed to
>> piping the whole output from one command into another)?
>
> That's pretty much how I understood it, although I disagree with the "as
> opposed to".. I don't see an "opposition"... more of an extension to the
> traditional pipe.
How do you disagree that manually copying and pasting command output vs.
vs. piping complete, unseen command output are very different?
(Or are you just familiar with "as opposed to" used to mean "as distinguished
from?)
(http://idioms.thefreedictionary.com/as+opposed+to,
http://www.thefreedictionary.com/as+opposed+to, sense #3; etc.)
Eric Gerlach
> > I also suggested the copying/pasting approach via gnu/screen's mechanism
> > but that's not really what the OP was asking and maybe there should be a
> > smarter alternative..??
> >
>
> Actually, it seems that copy-paste is in fact what I am looking for. I
> just figured that this would be common enough to be a part of the
> shell itself, not something that would require workarounds or hacks. I
> intend to learn screen.
If you're looking to take the output from a command, edit it, then pipe it back
into another command, may I suggest your favourite editor?
vim can do it like so (for example):
(in command mode)
!!ls
(edit to your heart's content)
:%!wc
I'm sure emacs can do it too, but I don't know emacs all that well.
Cheers,
--
Eric Gerlach, Network Administrator
Federation of Students
University of Waterloo
p: (519) 888-4567 x36329
e: eger...@feds.uwaterloo.ca
Dotan Cohen
> into another command, may I suggest your favourite editor?
>
> vim can do it like so (for example):
>
> (in command mode)
> !!ls
> (edit to your heart's content)
> :%!wc
>
> I'm sure emacs can do it too, but I don't know emacs all that well.
>
Thanks, Eric.
--
Dotan Cohen
http://what-is-what.com
http://gibberish.co.il
Foss User
<eger...@feds.uwaterloo.ca> wrote:
> On Tue, May 19, 2009 at 01:31:30PM +0300, Dotan Cohen wrote:
>> > I also suggested the copying/pasting approach via gnu/screen's mechanism
>> > but that's not really what the OP was asking and maybe there should be a
>> > smarter alternative..??
>> >
>>
>> Actually, it seems that copy-paste is in fact what I am looking for. I
>> just figured that this would be common enough to be a part of the
>> shell itself, not something that would require workarounds or hacks. I
>> intend to learn screen.
>
> If you're looking to take the output from a command, edit it, then pipe it back
> into another command, may I suggest your favourite editor?
>
> vim can do it like so (for example):
>
> (in command mode)
> !!ls
> (edit to your heart's content)
> :%!wc
>
> I'm sure emacs can do it too, but I don't know emacs all that well.
>
> Cheers,
I tried this:
$ which firefox | vim -
vim opened.
Now when I press !!
:.!
appears at bottom.
Next I type |s and I get this error:
/bin/bash: -c: line 0: syntax error near unexpected token `|'
/bin/bash: -c: line 0: `(|s) < /tmp/v754567/14 >/tmp/v754567/15 2>&1'
shell returned 2
Boyd Stephen Smith Jr.
wrote:
>> I also suggested the copying/pasting approach via gnu/screen's mechanism
>
>I
>just figured that this would be common enough to be a part of the
>shell itself,
Probably mostly for historical reasons, the shell doesn't handle terminal
manipulations. In particular, the shell doesn't know that the input you
want is 5 rows up and 12 columns over or have any (special) support for
moving the cursor to allow you to select something like that.
There are a lot of different terminals. Some don't even mix your input with
the shell (or other process's) output. A good shell works equally well with
any of them.
>not something that would require workarounds or hacks.
Additional tools are not "workarounds" or "hacks". They are separations of
duties/roles which allows a more flexible and robust environment.
Unix and Linux come from a culture were providing lots of generalized small
tools to the user was found to be more flexible than the alternatives,
because it allowed individual users and communities to build very
specialized tools without starting entirely from scratch.
It's not a problem that cat/sed/grep doesn't know how to convert your MS
Word Document to text, it isn't the role of that tool. It's not a problem
that LVM doesn't resize the filesystem before/after resizing the LV, it
isn't the role of that tool. It's not a problem that your shell doesn't
have copy-and-paste, it isn't the role of that tool.
Now, it may be that you need higher level tools. That's fine, but don't
complain that a spool of copper wire is not a jackhammer.
>I
>intend to learn screen.
AIUI, screen is quite scriptable and should be capable of sending output to
the process(es) attached to it. This would allow you to write "screen
scripts" that used the shell for what it is good at and used screen for what
it is good at.
Eric Gerlach
> On Tue, May 19, 2009 at 8:43 PM, Eric Gerlach
> <eger...@feds.uwaterloo.ca> wrote:
> > vim can do it like so (for example):
> >
> > (in command mode)
> > !!ls
> > (edit to your heart's content)
> > :%!wc
> >
> > I'm sure emacs can do it too, but I don't know emacs all that well.
> >
> > Cheers,
>
> I tried this:
>
> $ which firefox | vim -
>
> vim opened.
>
> Now when I press !!
>
> :.!
>
> appears at bottom.
>
> Next I type |s and I get this error:
>
> /bin/bash: -c: line 0: syntax error near unexpected token `|'
> /bin/bash: -c: line 0: `(|s) < /tmp/v754567/14 >/tmp/v754567/15 2>&1'
>
> shell returned 2
That wasn't a pipe character, it was a lowercase 'L'.
What '!!' does is pipe the current line into the command specified. I was
using that to load the result of an 'ls' into the buffer. This command
replaces what is on the current line with the result of the command.
Then the command :%!wc means the following
: - enter ex command mode
% - on the entire buffer
! - pipe through command
wc - the command to use (wc in this case)
You can replace the '%' with any vim motion in order to pipe only certain lines
through a command. You can even select an area in visual mode, type '!' and
then enter your command, and it will filter that area through the command.
Note that this always replaces what was there with the output of the command,
though.
Type :help filter in command mode for more information.
Cheers,
--
Eric Gerlach, Network Administrator
Federation of Students
University of Waterloo
p: (519) 888-4567 x36329
e: eger...@feds.uwaterloo.ca
Chris Jones
> Chris Jones wrote:
> > On Mon, May 18, 2009 at 04:13:16PM EDT, Barclay, Daniel wrote:
> >> Dotan Cohen wrote:
> >
> ...
> >
> >> Are you asking about manually selecting part of the output of a
> >> command(s) and using it to assemble another command (as opposed to
> >> piping the whole output from one command into another)?
> >
> > That's pretty much how I understood it, although I disagree with the "as
> > opposed to".. I don't see an "opposition"... more of an extension to the
> > traditional pipe.
>
> How do you disagree that manually copying and pasting command output vs.
> vs. piping complete, unseen command output are very different?
I didn't realize you meant using copy/paste - which obviously is totally
different from piping the output of a program to the input of another
program.
Compare:
$ cat Makefile | vim -
with
$ less Makefile
.. followed by a gnu copy/paste of the contents of "Makefile" into an
empty vim buffer for instance.
Using the second method, all those pesky <TAB> aka "^I" characters have
been replaced by spaces.
Andrei Popescu
> If you're looking to take the output from a command, edit it, then pipe it back
> into another command, may I suggest your favourite editor?
>
> vim can do it like so (for example):
>
> (in command mode)
> !!ls
> (edit to your heart's content)
> :%!wc
Building a bit on Eric's ideea:
$ first_command | pipedit second_command
where 'pipedit' is a small shell script (pseudocode):
stdin > /tmp/tempfile
$EDITOR /tmp/tempfile
$@ < /tmp/tempfile
rm /tmp/tempfile
The only trouble with this is that some commands need a '-' parameter to
read from stdin. It might be possible to solve it by greping for
specific keywords in the '--help' output of second_command.
Regards,
Andrei
--
If you can't explain it simply, you don't understand it well enough.
(Albert Einstein)
Tzafrir Cohen
> AIUI, screen is quite scriptable and should be capable of sending output to
> the process(es) attached to it. This would allow you to write "screen
> scripts" that used the shell for what it is good at and used screen for what
> it is good at.
And as you mentioned scripts, I'll mention script(1) again.
tzafrir@sweetmorn:~$ script /tmp/log
Script started, file is /tmp/log
tzafrir@sweetmorn:~$ which mozilla
/usr/bin/mozilla
tzafrir@sweetmorn:~$ exit
Script done, file is /tmp/log
tzafrir@sweetmorn:~$ cat /tmp/log
Script started on IDT 16:35:21 2009 מאי 20 ד'
tzafrir@sweetmorn:~$ which mozilla
/usr/bin/mozilla
tzafrir@sweetmorn:~$ exit
Script done on IDT 16:35:32 2009 מאי 20 ד'
--
Tzafrir Cohen | tza...@jabber.org | VIM is
http://tzafrir.org.il | | a Mutt's
tza...@cohens.org.il | | best
ICQ# 16849754 | | friend
Dotan Cohen
>>shell itself,
>
> Probably mostly for historical reasons, the shell doesn't handle terminal
> manipulations. In particular, the shell doesn't know that the input you
> want is 5 rows up and 12 columns over or have any (special) support for
> moving the cursor to allow you to select something like that.
>
> There are a lot of different terminals. Some don't even mix your input with
> the shell (or other process's) output. A good shell works equally well with
> any of them.
>
I see, thanks.
>>not something that would require workarounds or hacks.
>
> Additional tools are not "workarounds" or "hacks". They are separations of
> duties/roles which allows a more flexible and robust environment.
>
Correct, tools such as screen are not a hack. But this (suggested earlier) is:
$(ekiga 2>/dev/stdout | head -2 | tail -1)
> Unix and Linux come from a culture were providing lots of generalized small
> tools to the user was found to be more flexible than the alternatives,
> because it allowed individual users and communities to build very
> specialized tools without starting entirely from scratch.
>
> It's not a problem that cat/sed/grep doesn't know how to convert your MS
> Word Document to text, it isn't the role of that tool. It's not a problem
> that LVM doesn't resize the filesystem before/after resizing the LV, it
> isn't the role of that tool. It's not a problem that your shell doesn't
> have copy-and-paste, it isn't the role of that tool.
>
While in general I agree, I would assume that handling user input /
output is the role of the terminal (not the shell), and therefore
copy/paste falls into it's role.
> Now, it may be that you need higher level tools. That's fine, but don't
> complain that a spool of copper wire is not a jackhammer.
>
Not once did I complain! I asked how to do what I need, but I did not
complain that it is not done how I would prefer.
>> I intend to learn screen.
>
> AIUI, screen is quite scriptable and should be capable of sending output to
> the process(es) attached to it. This would allow you to write "screen
> scripts" that used the shell for what it is good at and used screen for what
> it is good at.
Thanks, Boyd.
Boyd Stephen Smith Jr.
>I would assume that handling user input /
>output is the role of the terminal (not the shell), and therefore
>copy/paste falls into it's role.
Oh, yes. I agree. Physical terminals (even the Linux VCs) are generally a
let down as are many terminal applications. However, with liberal
application of GNU Screen, TinTin++, and Expect you can script just about
anything that happens entirely within a terminal.
Chris Bannister
As has been mentioned already! "apt-get install gpm"
works a treat, in fact, would classify it as an essential cli tool.
apt-cache show gpm
Description: General Purpose Mouse interface
[..]
By default, the daemon provides a 'selection' mode, so that
cut-and-paste with the mouse works on the console just as it does
under X.
Select by holding left mouse-button down and dragging. Paste by pressing
middle mouse-button.
--
Chris.
======
I contend that we are both atheists. I just believe in one fewer god
than you do. When you understand why you dismiss all the other
possible gods, you will understand why I dismiss yours.
-- Stephen F Roberts
Osamu Aoki
> On Tue, May 19, 2009 at 01:31:30PM +0300, Dotan Cohen wrote:
> > Actually, it seems that copy-paste is in fact what I am looking for. I
>
> As has been mentioned already! "apt-get install gpm"
> works a treat, in fact, would classify it as an essential cli tool.
FYI: It used to be installed as some default but X installation
complication made gpm out as I remember. It is nice.
Chris Jones
> On Tue, May 19, 2009 at 01:31:30PM +0300, Dotan Cohen wrote:
> > Actually, it seems that copy-paste is in fact what I am looking for.
>
> As has been mentioned already! "apt-get install gpm" works a treat, in
> fact, would classify it as an essential cli tool.
The OP was initially asking for a mouseless solution:
"without retyping (and without using the mouse, which I often do not
have)."
Not sure why, but as to myself, when I'm typing away in a terminal, the
last thing I want is to have to reach for a mouse.
I guess I've been spoiled by gnu/screen.
CJ
Barclay, Daniel
Chris Bannister wrote:
...
>
> apt-cache show gpm
> Description: General Purpose Mouse interface
> [..]
> By default, the daemon provides a 'selection' mode, so that
> cut-and-paste with the mouse works on the console just as it does
> under X.
Speaking of gpm _and_ X: Can gpm be connected X's selection mechanism
so one can copy text from a virtual console and paste it into X, and
vice versa?