On Tue, Apr 8, 2025 at 8:54 AM MacBeth <macbeth.112...@gmail.com> wrote: > > On Mon, Apr 7, 2025 at 5:37 PM A. James Lewis <ja...@fsck.co.uk> wrote: > > > > I have always attempted to avoid > > using external programs where functionality within bash can meet a > > requirement. Doing this allows my scripts to be more reliable, and not > > depend on those external tools being installed... > > > > I have however found it extremely frustrating to open TCP connections > > via /dev/tcp, because there appears to be no way to control the > > timeout! This means I cannot "try one server and move on to the next > > if it's not responding" etc... the default timeout is quite long, so > > even a simple script to check a list of servers for a response on a > > given port is problematic. > > > > I realise that the action can be performed in a subshell, with the use > > of "timeout", but to my knowledge, a file descriptor cannot be passed > > back from that subshell, which makes communicating with a remote system > > once the connection is open quite challenging/inconvenient. > > >
BTW, this phenomenon is not specific to /dev/tcp and /dev/udp connections. Bash blocks if my USB HDD needs 20 or so seconds to spin up, so I would guess a timeout control would/could help any bash redirection I/O blocking. > > #### script begin > > cat >&3 <<-EOT > $method $path HTTP/1.0 > Host: $host > Connection: close > EOT > #### script end ... again, the text paste messed up, insert a blank line after the "Connection: close" line.
