The GNU Bourne-Again SHell - Patches: patch #8829, Allow redirection to listen for a...
You are not allowed to post comments on this tracker with your current authentication level.
patch #8829: Allow redirection to listen for a TCP connection
Submitter: | Warren He <warrenhe> | ||
Submitted: | Thu 10 Dec 2015 01:51:27 AM UTC | ||
Category: | None | Priority: | 5 - Normal |
Status: | Done | Privacy: | Public |
Assigned to: | None | Open/Closed: | Open |
Wed 31 May 2017 04:30:05 PM UTC, comment #1: |
George Caswell <tetsujin> |
Thu 10 Dec 2015 01:51:27 AM UTC, original submission:
This patch makes redirection to/from `/dev/tcp-listen/interface/port` listen for a TCP connection.
If the specified interface is a hostname that resolves to multiple addresses, it won't listen to all of them simultaneously. For example, if `localhost` is both `127.0.0.1` and `::1`, `/dev/tcp-listen/localhost/1234` won't listen on `::1` unless it fails to listen on `127.0.0.1`. |
Warren He <warrenhe> |
Depends on the following items: None found
Items that depend on this one: None found
There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.
My concern about this approach is that it only allows for accepting a single incoming connection each time the port is bound.
If the shell were to provide socket()+bind() as one operation, and then accept() as another operation, that would allow for more flexibility in how scripts deal with incoming connections, including the ability to accept multiple connections - and for users who want the simplicity of taking a single incoming connection, such a command could be implemented as a function using the socket()+bind() and accept() commands.
/dev/tcp redirection is useful, but it's also a bit strange for the shell to spoof the existence of non-existent device files so it can express TCP connections through redirection. Ideally I would say the shell shouldn't do this (at least, since it already does it, it shouldn't do it more) - but on the other hand, expressing TCP connection as redirection does allow for the connection to be limited to the scope of a command or group of commands, whereas using builtins to connect would require explicitly closing the connection files when done with them.
You can, for instance:
while read word; do respond_to "${word}"; done <> /dev/tcp/whatever
As opposed to:
tcp_connect hostname:port socket_varname # Open TCP connection, store FD number in ${socket_varname}
while read word; do respond_to "${word}"; done <>&$socket_varname
exec {socket_varname}<>&- # Close the connection FD
So the /dev/tcp style of approach does have its benefits, but I think it may be worth considering whether it really should be expanded.