can someone please test this shell snippet for me?
bsh
I am not currently able to test the following two lines of
ksh(1) code. May I presume that you provide the output
of the [two] following shell code snippets? It _should_ be
able to work on bash3 as well. Please indicate the shell
and version.
Error output too, please... I expect that it is the _error_
output that will tell me if they are sufficient for an idea
that I have been trying to test.
The following code (as per the manpage) requires the /dev/fd
pseudo filesystem be correctly installed for the following
to work. Also, run interactively, as an error in the file
argument of the "." (source) builtin will terminate the
current process, and I wouldn't want you to experience
data loss for the favor of helping me....
. <(cat /dev/tcp/127.0.0.1/13)
. <(cat </dev/tcp/127.0.0.1/13)
Thanks in advance!
=Brian
Chris F.A. Johnson
Both and the command prompt and in a script, in both bsh3
(3.2.3(3)-release) and ksh93 (Version M 1993-12-28 n), I get:
$ cat /dev/tcp/127.0.0.1/13
/usr/local/bin/ksh93: cat: /dev/tcp/127.0.0.1/13: cannot open [No such file or directory]
$ cat </dev/tcp/127.0.0.1/13
/usr/local/bin/ksh93: /dev/tcp/127.0.0.1/13: cannot open [Connection refused]
$ . <(cat /dev/tcp/127.0.0.1/13)
/usr/local/bin/ksh93: cat: /dev/tcp/127.0.0.1/13: cannot open [No such file or directory]
$ . <(cat </dev/tcp/127.0.0.1/13)
/usr/local/bin/ksh93: /dev/tcp/127.0.0.1/13: cannot open [Connection refused]
With the normal method of opening a socket, I get the same thing:
$ exec <> /dev/tcp/127.0.0.1/13
/usr/local/bin/ksh93: /dev/tcp/127.0.0.1/13: cannot create [Connection refused]
Presumably, it requires a time server running.
--
Chris F.A. Johnson, author <http://cfaj.freeshell.org/shell/>
Shell Scripting Recipes: A Problem-Solution Approach (2005, Apress)
===== My code in this post, if any, assumes the POSIX locale
===== and is released under the GNU General Public Licence
Chris F.A. Johnson
> On Mar 18, 9:08 am, "Chris F.A. Johnson" <cfajohn...@gmail.com> wrote:
>> On 2007-03-17, bsh wrote:
>> > ...
>> With the normal method of opening a socket, I get the same thing.
>
> (I needed to demonstrate sourcing from process substitition, by which
> stdout must be used.)
>
>> $ exec <> /dev/tcp/127.0.0.1/13
>> /usr/local/bin/ksh93: /dev/tcp/127.0.0.1/13: cannot create [Connection refused]
>> Presumably, it requires a time server running.
>
> I had wanted to determine if ksh accepted sourcing from process
> substitution, and that network I/O was sufficient to fulfill this from
> stdout.
>
> Perhaps then, if a more suitable construct could be used, as I
> was not really interested in the timeserver, but wanted at least
> to used _some_ ubiquitous network port or daemon or file which
> I could rely on being available. I couldn't think of any, and expected
> to see something like: "ksh: error: Sun: no such process."
>
> Can you try again perhaps:
>
> . <(cat <any-file-you-want)
>
> (The same caveat applies; source only from a file that is would
> be suitable to not crash or corrupt your system and/or account).
$ . <(cat < /dev/tcp/127.0.0.1/119/)
/usr/local/bin/ksh93: /dev/tcp/localhost/119/: cannot open [No such file or directory]
$ . <(cat /dev/tcp/127.0.0.1/119/)
/usr/local/bin/ksh93: cat: /dev/tcp/localhost/119/: cannot open [No such file or directory]
$ telnet 127.0.0.1 119
Trying 127.0.0.1...
Connected to ... (127.0.0.1).
Escape character is '^]'.
200 Leafnode NNTP Daemon, version 1.10.4.rel running at localhost.localdomain (fqdn: ...)
Bill Marcum
<cfajo...@gmail.com> wrote:
>
> $ . <(cat < /dev/tcp/127.0.0.1/119/)
> /usr/local/bin/ksh93: /dev/tcp/localhost/119/: cannot open [No such
> file or directory]
> $ . <(cat /dev/tcp/127.0.0.1/119/)
> /usr/local/bin/ksh93: cat: /dev/tcp/localhost/119/: cannot open [No
> such file or directory]
> $ telnet 127.0.0.1 119
> Trying 127.0.0.1...
> Connected to ... (127.0.0.1).
> Escape character is '^]'.
> 200 Leafnode NNTP Daemon, version 1.10.4.rel running at
> localhost.localdomain (fqdn: ...
>
for /dev/tcp by default.
--
/* And you'll never guess what the dog had */
/* in its mouth... */
-- Larry Wall in stab.c from the perl source code
bsh
Darn it! When will the OS and software configurators realise that the
most valuable attribute of the shell is the ubiquity of feature sets?
I
had an idea (which I still think I could make work) that now I think
is
not worth the time insofar as the canonical, documented functionality
upon which it is built would probably not even be asserted in the OS
or the language....
*Sigh*.
Thanks for the effort, Chris and Bill. One last request: is there
anyone
out there for whom the above snippet _does_ work? (That is not to
say that it gives a successful return code, but that the underlying
process substitution and source (".") builtin works).
=Brian
Chris F.A. Johnson
> Bill Marcum <marcumb...@bellsouth.net> wrote:
>> Chris F.A. Johnson <cfajohn...@gmail.com> wrote:
>> > $ . <(cat < /dev/tcp/127.0.0.1/119/)
>> /usr/local/bin/ksh93: /dev/tcp/localhost/119/: cannot open [No such ...
>
> Darn it! When will the OS and software configurators realise that the
> most valuable attribute of the shell is the ubiquity of feature sets?
> I had an idea (which I still think I could make work) that now I
> think is not worth the time insofar as the canonical, documented
> functionality upon which it is built would probably not even be
> asserted in the OS or the language....
Isn't /dev/tcp a construct of the shell itself, and not part of
the OS?
Stephane CHAZELAS
> On 2007-03-19, bsh wrote:
>> Bill Marcum <marcumb...@bellsouth.net> wrote:
>>> Chris F.A. Johnson <cfajohn...@gmail.com> wrote:
>>> > $ . <(cat < /dev/tcp/127.0.0.1/119/)
>>> /usr/local/bin/ksh93: /dev/tcp/localhost/119/: cannot open [No such ...
>>
>> Darn it! When will the OS and software configurators realise that the
>> most valuable attribute of the shell is the ubiquity of feature sets?
>> I had an idea (which I still think I could make work) that now I
>> think is not worth the time insofar as the canonical, documented
>> functionality upon which it is built would probably not even be
>> asserted in the OS or the language....
>
> Isn't /dev/tcp a construct of the shell itself, and not part of
> the OS?
Yes, of some versions of ksh and bash, which means its confusing
as it only works for redirections. Yet another clumsy /feature/
of ksh. Depending on the version of ksh, names for the address
and port may not be recognised.
zsh has a ztcp builtin to create and handle TCP sockets. There's
no equivalent to /dev/udp though.
--
Stéphane
bsh
> Chris F.A. Johnson wrote:
> > bsh wrote:
> > > Bill Marcum <marcumb...@bellsouth.net> wrote:
> > > > Chris F.A. Johnson <cfajohn...@gmail.com> wrote:
> > > > $ . <(cat < /dev/tcp/127.0.0.1/119/)
> > > most valuable attribute of the shell is the ubiquity of feature sets?
Process substitution is by default asserted on few--if any--
kornshells that I've had the opportunity to use on various hosts.
/dev/@(tcp,udp) was introduced in ksh version 1988. Although I
would have to consult my source for ksh 1988, IIRC it was _not_
a merely a compile-time feature implemented via conditional
compilation; however, process substitution is contingent (as is
related in the manpage) on the /dev/fd filessystem.
> > Isn't /dev/tcp a construct of the shell itself, and not part of the OS?
It is, but... Once, though, I did notice that on an Irix5 system,
which already had a "real" /dev/fd filesystem, the similar ksh
facility was "shrouded." This is the only case for this facility
being affected by the OS.
> Yes, of some versions of ksh and bash, which means its confusing
> as it only works for redirections. Yet another clumsy /feature/
> of ksh.
Where else would would network I/O come from, if not from
redirection or coprocess?
> Depending on the version of ksh, names for the address and port
> may not be recognised.
I do not know of any version of ksh, including ksh1993, that
does DNS name resolution with the /dev/@(udp,tcp) feature.
It would be easy to add with sufficient discipline functions in
ksh1993, though. The weakness is, and continues to be (as
indeed is my dilemma), that ksh is susceptible to the
build configuration of the host OS.
My intention, as previously hinted at, was to extend
autoloading to use network I/O. I'm also trying to create a
CPAN-like resource for bash/ksh. Implementing this
using a built-in facility of ksh is obviously preferable.
Incidentally, Geoff Fowler has included a script "hurl"
("Http-URL") in both sh and ksh1993 versions within
the "AST-INIT" package available through kornshell.com.
It uses four different techniques/applications to allow
webpage retrieval. I was perhaps thinking:
. <( cat </dev/tcp/$ip/80/file )
or:
. <( hurl url )
"hurl":
<AST-INIT>/src/cmd/INIT/hurl.sh
http://public.research.att.com/~gsf/man/man1/hurl.html
An interesting whitepaper:
"Network Your Shell Scripts with Netpipes":
http://www.onlamp.com/pub/a/onlamp/2004/05/27/netpipes.html
=Brian
Stephane CHAZELAS
[...]
> /dev/@(tcp,udp) was introduced in ksh version 1988. Although I
> would have to consult my source for ksh 1988, IIRC it was _not_
> a merely a compile-time feature implemented via conditional
> compilation; however, process substitution is contingent (as is
> related in the manpage) on the /dev/fd filessystem.
zsh's implementation of ksh can use named pipes (and temporary
files for =(...)). bash can also use named pipes.
[...]
>> Yes, of some versions of ksh and bash, which means its confusing
>> as it only works for redirections. Yet another clumsy /feature/
>> of ksh.
>
> Where else would would network I/O come from, if not from
> redirection or coprocess?
What I meant is that using a virtual file was a bad idea.
Most people think /dev/tcp/... is handled by the system.
And I can't blame them, /dev/tcp even happens to exist on most
SysV based Unix systems.
Then they do: ... | tee /dev/tcp/foo/bar and don't understand
why it doesn't work.
A more sensible approach would have
been something like:
cmd > TCP(flags:host:port) for instance.
It has it's limitations. For instance on the read side, that <,
> paradygm doesn't fit well to handle several incoming
connections.
It is better handled by a builtin like in zsh.
>> Depending on the version of ksh, names for the address and port
>> may not be recognised.
>
> I do not know of any version of ksh, including ksh1993, that
> does DNS name resolution with the /dev/@(udp,tcp) feature.
Was introduced in ksh93f according to ksh93's RELEASE file. It's
also in bash. zsh's ztcp also handles host names.
> It would be easy to add with sufficient discipline functions in
> ksh1993, though. The weakness is, and continues to be (as
> indeed is my dilemma), that ksh is susceptible to the
> build configuration of the host OS.
>
> My intention, as previously hinted at, was to extend
> autoloading to use network I/O. I'm also trying to create a
> CPAN-like resource for bash/ksh. Implementing this
> using a built-in facility of ksh is obviously preferable.
What about doing it for intercal while you're at it :)
> Incidentally, Geoff Fowler has included a script "hurl"
> ("Http-URL") in both sh and ksh1993 versions within
> the "AST-INIT" package available through kornshell.com.
> It uses four different techniques/applications to allow
> webpage retrieval. I was perhaps thinking:
>
> . <( cat </dev/tcp/$ip/80/file )
eval "$(wget -qO- http://...)"
--
Stéphane
Roland Mainz
> 2007-03-23, 17:06(-07), bsh:
[snip]
> > Where else would would network I/O come from, if not from
> > redirection or coprocess?
>
> What I meant is that using a virtual file was a bad idea.
> Most people think /dev/tcp/... is handled by the system.
> And I can't blame them, /dev/tcp even happens to exist on most
> SysV based Unix systems.
>
> Then they do: ... | tee /dev/tcp/foo/bar and don't understand
> why it doesn't work.
Uhm... ksh93's libcmd has a "tee" builtin which should AFAIK be able to
handle this...
> A more sensible approach would have
> been something like:
>
> cmd > TCP(flags:host:port) for instance.
Erm, '(', ':' and ')' are valid filesystem characters - that construct
above would cause problems if you want to access files which are named
"TCP(flags:host:port)".
> It has it's limitations. For instance on the read side, that <,
> > paradygm doesn't fit well to handle several incoming
> connections.
>
> It is better handled by a builtin like in zsh.
ksh93 has the "open" builtin for this purpose...
----
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) roland...@nrubsig.org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
Roland Mainz
> 2007-03-20, 11:42(-04), Chris F.A. Johnson:
> > On 2007-03-19, bsh wrote:
> >> Bill Marcum <marcumb...@bellsouth.net> wrote:
> >>> Chris F.A. Johnson <cfajohn...@gmail.com> wrote:
> >>> > $ . <(cat < /dev/tcp/127.0.0.1/119/)
> >>> /usr/local/bin/ksh93: /dev/tcp/localhost/119/: cannot open [No such ...
> >>
> >> Darn it! When will the OS and software configurators realise that the
> >> most valuable attribute of the shell is the ubiquity of feature sets?
> >> I had an idea (which I still think I could make work) that now I
> >> think is not worth the time insofar as the canonical, documented
> >> functionality upon which it is built would probably not even be
> >> asserted in the OS or the language....
> >
> > Isn't /dev/tcp a construct of the shell itself, and not part of
> > the OS?
>
> Yes, of some versions of ksh and bash, which means its confusing
> as it only works for redirections.
Erm... that's not correct. It works for any file opened by the libshell
function |sh_open()|, e.g. redirections and the "open" builtin will
handle it... AFAIK ksh93/libcmd's "tee" builtin may work, too...
> Yet another clumsy /feature/
> of ksh. Depending on the version of ksh, names for the address
> and port may not be recognised.
That should be fixed since ksh93s (the code has been revamped for IPv6,
mobile IPv6 and SCTP (via /dev/sctp/<hostname>/<servicename>) support),
assuming "getent services <servicename>" and "getent hosts <hostname>"
are working.
Stephane CHAZELAS
[...]
>> cmd > TCP(flags:host:port) for instance.
>
> Erm, '(', ':' and ')' are valid filesystem characters - that construct
> above would cause problems if you want to access files which are named
> "TCP(flags:host:port)".
But they are special to the shell.
You can't write cmd > TCP(flags:host:port) as shells are now.
If you wanted to write to the file called TCP(flags:host:port),
you could the do:
cmd > "TCP(flags:host:port)"
as you already do now.
--
Stéphane
Roland Mainz
> 2007-04-02, 05:09(+02), Roland Mainz:
> [...]
> >> cmd > TCP(flags:host:port) for instance.
> >
> > Erm, '(', ':' and ')' are valid filesystem characters - that construct
> > above would cause problems if you want to access files which are named
> > "TCP(flags:host:port)".
>
> But they are special to the shell.
>
> You can't write cmd > TCP(flags:host:port) as shells are now.
How should this work if "host" contains any special characters (for
example '[', ']', ':' etc. which may be used for an IPv6 address) ?
Stephane CHAZELAS
> Stephane CHAZELAS wrote:
>> 2007-04-02, 05:09(+02), Roland Mainz:
>> [...]
>> >> cmd > TCP(flags:host:port) for instance.
>> >
>> > Erm, '(', ':' and ')' are valid filesystem characters - that construct
>> > above would cause problems if you want to access files which are named
>> > "TCP(flags:host:port)".
>>
>> But they are special to the shell.
>>
>> You can't write cmd > TCP(flags:host:port) as shells are now.
>
> How should this work if "host" contains any special characters (for
> example '[', ']', ':' etc. which may be used for an IPv6 address) ?
That was an idea. I'm not saying that one should implement it
exactly this way (for instance, host:port:flags would make more
sense), but that I think that something along those lines would
make more sense than /dev/tcp/host/port that is confusing and
misleading.
Make it
TCP(host/port/flags) if you want, or TCP(host;port[;flags])
and then TCP6(...), SCTP(...), UDP(...)...
--
Stéphane