John McKown wrote:
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}
News to me. Filed for future trial and use.
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.
but how does one carry on a sensible conversation? I can send stuff to
sendmail, but how do I get its responses?
16:23 [sum...@bobtail ~]$ ls -l /dev/tcp/ns
ls: /dev/tcp/ns: No such file or directory
16:24 [sum...@bobtail ~]$ ls -l /dev/tcp/ns:22
ls: /dev/tcp/ns:22: No such file or directory
16:24 [sum...@bobtail ~]$ echo /dev/tcp/ns:22
/dev/tcp/ns:22
16:24 [sum...@bobtail ~]$ echo >/dev/tcp/ns:22
bash: /dev/tcp/ns:22: No such file or directory
16:24 [sum...@bobtail ~]$ echo >/dev/tcp/ns/22
16:24 [sum...@bobtail ~]$ echo >/dev/tcp/ns/25
16:24 [sum...@bobtail ~]$ echo >/dev/tcp/ns/25 | cat /dev/tcp/ns/25
cat: /dev/tcp/ns/25: No such file or directory
16:25 [sum...@bobtail ~]$ echo >/dev/tcp/ns/25 | cat </dev/tcp/ns/25
220 ns.demo.lan ESMTP Postfix
16:25 [sum...@bobtail ~]$ cat </dev/tcp/ns/25&
[1] 14558
16:25 [sum...@bobtail ~]$ 220 ns.demo.lan ESMTP Postfix
echo quit >/dev/tcp/ns/25
16:25 [sum...@bobtail ~]$
16:25 [sum...@bobtail ~]$ echo quit >/dev/tcp/ns/25
16:25 [sum...@bobtail ~]$
===
<( 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...
I think this sort of thing is a bit OS-dependent. It works with some
(2.4 and later I suspect) Linux kernels, likely not with *BSD, Solaris
and such, but I don't have any alternative systems to test on.
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 )
The above I know about and, on occasion I've fed two streams into diff.
There is also this:
generateSomeStuff | tee /dev/tty | consumeSomeStuff
which only works when there's a tty available (ie not do daemonised
processes)
and
could be combined with 1 above to log what's sent or received.
There is also this:
(echo >&5) 5>tempfile
where tempfile could be something above. I've used this sometimes in
scripts: think of any kind of program that produces more than one report
and you will find a use.
Copy this into your bash session:
\rm tempfile ;(ls -l >&5) 5>tempfile;ls -l tempfile
For more,
man bash
and look for
redirection
process substitution
command substitution
Some of the material there is new to me, I assume it's new in bash 3.x.
--
Cheers
John
-- spambait
[email protected] [email protected]
-- Advice
http://webfoot.com/advice/email.top.php
http://www.catb.org/~esr/faqs/smart-questions.html
http://support.microsoft.com/kb/555375
You cannot reply off-list:-)
----------------------------------------------------------------------
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
