On Tue, Apr 8, 2025 at 7:04 AM Greg Wooledge <g...@wooledge.org> wrote: > > On Tue, Apr 08, 2025 at 06:34:50 +0300, Oğuz wrote: > > On Tuesday, April 8, 2025, A. James Lewis <ja...@fsck.co.uk> wrote: > > > 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! > > > > Same. It'd be nice if bash gave up after $TMOUT seconds > > I would prefer a different variable, rather than assigning a second > meaning to an existing one.
TMOUT If set to a value greater than zero, the read builtin uses the value as its default timeout. The select command terminates if input does not arrive after TMOUT seconds when input is coming from a terminal. In an interactive shell, the value is interpreted as the number of seconds to wait for a line of input after issuing the primary prompt. Bash terminates after waiting for that number of seconds if a complete line of input does not arrive. A *fourth* meaning. Is there a good tutorial on how to actually use /dev/tcp? I imagine you've got to write and send HTTP request headers and then read and handle response headers yourself. If it were possible to use /dev/tcp to maintain a consistent session between multiple calls to curl, for instance, that might make it a lot more useful. At some point, it's going to be faster to call an external program than to try to do everything in pure bash, and it'll certainly be faster to write and more complete.
