OK, likely another "you didn't know that?!?" type observation. But I found
it interesting anyway.
First: using redirection to write to or read from an IP port
command >/dev/tcp/${HOST}/${PORT}
will establish a TCP connection to ${PORT} on ${HOST}. Replace
/dev/tcp/... with /dev/udp/... and it will do udp instead of tcp. This
redirects stdout. Of course, using < instead of > will redirect stdin and
do a read. So, if you like "netcat" to send some data ala
command | nc ${HOST} ${PORT}
you can use the above > redirection instead and
command </dev/tcp/${HOST}/${PORT}
instead of
nc -l ${HOST} ${PORT} | command
NBD - but it saves forking a process.
===
<( command ) and >( command )
Another nifty, similar to doing $( command ), except that the "command"
input for <( command ) or "command" output for >( command ) is available
for writing by the "outer" command via a /dev/fd/n file or the "command"
input for <( command ) is available for reading by the "outer" command via
a /dev/fd/n.
Although this is an interesting way to "pipe", I already have a work
around.
Example:
cmd1 infile1 infile2 infile3 >( cmd2 )
assumes cmd1 cannot write its output to stdout, so a normal pipe won't
work. But it can be done via:
cmd1 infile1 infile2 infile3 /dev/fd1 | cmd2
cmd1 <( cmd2 ) ..parms...
can be be done via:
cmd2 | cmd1 /dev/fd/0 ...parms...
where cmd1 cannot read its input from stdin for some reason.
Of course if you need more than one, the above work arounds don't work,
such as:
cmd1 infile1 infile2 outfile1 outfile2
could be
cmd1 <( cmd2 ) <( cmd3 ) >( cmd4 ) >( cmd5 )
===
OK, back to my hole.
--
Q: What do theoretical physicists drink beer from?
A: Ein Stein.
Maranatha!
John McKown
----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
