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.
|
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.
Follow 3 latest changes.
Date | Changed by | Updated Field | Previous Value | => | Replaced by |
---|---|---|---|---|---|
2020-04-14 | chet | Status | None | Done | |
2015-12-10 | warrenhe | Carbon-Copy | - | Added -email is unavailable- | |
2015-12-10 | warrenhe | Attached File | - | Added 0001-dev-tcp-listen-interface-port.patch, #35683 |
Powered by Savane 3.13-d3ae.
Corresponding source code
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.