Re: /dev/tcp feature request...
On Tue, Apr 8, 2025 at 8:54 AM MacBeth wrote: > > On Mon, Apr 7, 2025 at 5:37 PM A. James Lewis 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.
Re: /dev/tcp feature request...
On Tue, Apr 8, 2025 at 7:16 AM Zachary Santer wrote: > > Is there a good tutorial on how to actually use /dev/tcp? > I found a number of helpful results on google... https://www.google.com/search?q=%2Fdev%2Ftcp For instance: https://medium.com/@stefanos.kalandaridis/bash-ing-your-network-f7069ab7c5f4
Re: /dev/tcp feature request...
On Tue, Apr 8, 2025 at 7:04 AM Greg Wooledge wrote: > > On Tue, Apr 08, 2025 at 06:34:50 +0300, Oğuz wrote: > > On Tuesday, April 8, 2025, A. James Lewis 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.
Problem in trap help message
Translating bash 5.3-pre1, I faced a string change in trap's help message that I didn't quite understand. The phrase in 5.3-pre1: --- If a SIGNAL_SPEC is DEBUG, ACTION is executed before every simple command and selected other commands. --- The "and selected other commands" part was added in this new release. Can this please be clarified? Best regards, Rafael
Re: /dev/tcp feature request...
On Tue, Apr 08, 2025 at 06:34:50 +0300, Oğuz wrote: > On Tuesday, April 8, 2025, A. James Lewis 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.
Re: /dev/tcp feature request...
On Mon, Apr 7, 2025 at 5:37 PM A. James Lewis 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.
>
How about doing the entire connection in a function? That would allow
using a file descriptor how you want to... even if it means only using
it to be quick and check if a server is hanging, if your script is
otherwise wanting to do some complex (time consuming) interaction with
the server.
If you are open to basic external commands like ps and sleep, the
below is a way to control the timeout with current bash functionality.
script begin
maxdur=50 # 5 seconds (x0.1)
port=80
method=GET path=/
#method=OPTIONS path='*'
hosts()
{
cat <<-EOT
www.google.com
www.example.com
8.8.8.9
EOT
# 8.8.8.8 is Google DNS
# I made up the increment
}
chat()
{
exec 3<> /dev/tcp/$host/$port
cat >&3 <<-EOT
$method $path HTTP/1.0
Host: $host
Connection: close
EOT
# use &4 to bypass &1/2 output drop for bash errors
cat <&3 | head -n 1 >&4
exec 3<&-
}
hosts |
while read host; do
# drop bash errors on eventual timeout
chat 4>&1 > /dev/null 2>&1 &
dur=0
while ((dur /dev/null; do
sleep 0.1
((dur+=1))
(((dur%10)==0)) &&
echo "sleeping... waiting on $host"
done
# kill the connection/chat if it's still trying
ps -p $! > /dev/null && kill $!
echo "Done with: $host"
done
script end
ps. You can put tabs before lines within the heredocs, including the
end EOT lines, but the tab character doesn't paste into gmail
webmail... :/
Re: /dev/tcp feature request...
On Tue, Apr 8, 2025 at 8:54 AM MacBeth wrote: > > script begin ... sample output being: $ . tcp.sh HTTP/1.0 200 OK Done with: www.google.com HTTP/1.0 200 OK Done with: www.example.com sleeping... waiting on 8.8.8.9 sleeping... waiting on 8.8.8.9 sleeping... waiting on 8.8.8.9 sleeping... waiting on 8.8.8.9 sleeping... waiting on 8.8.8.9 Done with: 8.8.8.9
Re: Problem in trap help message
On 4/8/25 3:55 PM, Rafael Fontenelle via Bug reports for the GNU Bourne Again SHell wrote: Translating bash 5.3-pre1, I faced a string change in trap's help message that I didn't quite understand. The phrase in 5.3-pre1: --- If a SIGNAL_SPEC is DEBUG, ACTION is executed before every simple command and selected other commands. --- The "and selected other commands" part was added in this new release. Can this please be clarified? The DEBUG trap is executed before simple commands and several compound commands: for, arithmetic for, select, case, before the first command in a shell function, [[ conditional commands, and (( arithmetic commands. This is documented in the man page, but I feel like it's overkill to put it in the help text. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: Support ksh93 x=${cmd;}
Cedric Blancher writes:
> Good morning!
>
> Could bash please support x=${cmd;} alongside x=$(cmd)?
>
> x=$(cmd;} works like x=$(cmd), except that cmd does not run in
> a subshell, i.e. the stdout within ${cmd;} is redirected to the
> variable "x", but any other changes of variables (global/static/local)
> are also available outside ${}, unlike $()
>
> can be anything of blank, tab, newline. The cmd must ALWAYS be
> terminated with a ";".
>
> Example:
> ksh93 -c 'out_stderr="${ { out_stdout="${ ls x ; (( out_res=$? )) ; }"
> ; } 2>&1 ; }" ; printf "stdout=%q, stderr=%q, exit code=%d\n"
> "$out_stdout" "$out_stderr" "$out_res"'
> stdout='', stderr=$'ls: cannot access \'x\': No such file or
> directory', exit code=2
See https://lists.gnu.org/archive/html/bug-bash/2025-04/msg00023.html.
Bash-5.3-rc1 available
The first release candidate of bash-5.3 is now available with the URLs ftp://ftp.cwru.edu/pub/bash/bash-5.3-rc1.tar.gz https://ftp.gnu.org/pub/gnu/bash/bash-5.3-rc1.tar.gz and from the bash-5.3-testing branch in the bash git repository (http://git.savannah.gnu.org/cgit/bash.git/log/?h=bash-5.3-testing). You can use git clone --branch bash-5.3-testing git://git.savannah.gnu.org/bash.git to clone the testing branch. The CWRU FTP site works best if your client supports Extended Passive (EPSV) mode. This tar file includes the formatted documentation (you should be able to generate updated versions yourself). This release fixes several outstanding bugs in bash-5.2 and introduces a number of new features. There are significant new features of note: * There is a new form of command substitution that executes the command in the current shell execution context. Two forms are implemented: one that reads the command substitution's output and another that expects to find the result in the REPLY shell variable when the command substitution completes. * The GLOBSORT shell variable determines how the shell will sort the results of pathname completion. * The compgen builtin has an option to put the generated completions into a designated shell variable instead of writing them to the standard output. * The read builtin has a new `-E' option that uses readline with the default bash completion, including programmable completion. * The source builtin has a new `-p PATH' option, which makes it use the PATH argument instead of $PATH to search for the file. The source code has been updated for C23 conformance. This means that bash will no longer compile with K&R-style C compilers. Readline has a new option that allows case-insensitive searching, a new command that executes a named readline command, and a new command that exports possible word completions in a specified format for consumption by another process. There are several notable bug fixes. The shell no longer marks jobs as notified in several cases where it did before without actually notifying the user. There are changes for POSIX conformance in areas where POSIX is evolving. There is a set of fixes that improve behavior when command status is being inverted while `set -e' is enabled. The intl library has been updated to the one from gettext-0.21.1. Bash does a much better job of handling integer overflow in places like the printf builtin. A complete list of changes is appended. There are a few incompatible changes between bash-5.2 and bash-5.3. The test builtin uses slightly different parsing behavior when parenthesized subexpressions are present and test has been supplied more than four arguments, for compatibility with coreutils. When the shell is running interactively, it no longer notifies about completed jobs while sourcing a script, deferring notification until the script completes. `bashbug' may be used to report bugs with this version. It will send mail to chet.ra...@case.edu if the shell's `release status' is alpha or beta. As always, thanks for your help. Chet +== CHANGES ==+ This document details the changes between this version, bash-5.3-rc1, and the previous version, bash-5.3-beta. 1. Changes to Bash a. Fixed a bug where backslash did not quote multibyte characters in some cases. b. Requesting the length of an element of an unset array is a fatal error when `set -u' is enabled and the subscript is not `@' or `*'. c. Prompt expansion now quotes the results of \U. d. Changes to `set -e' exit behavior in posix mode, since POSIX now says to exit as if executing the `exit builtin with no arguments'. e. Fixes to the `exec' builtin to undo redirections if it is given a command name to execute and the exection fails, but the shell does not exit. This is POSIX interp 1896. f. Fixed a bug that resulted in `wait' setting $? to 255 in some cases when waiting for a specific PID. g. Fixed a bug involving redirections to the file descriptor bash is using to read a script. h. In POSIX mode, `kill' returns a failure status if any of the PID/job arguments are not found or if sending the signal fails. i. Fixed a bug that caused an invalid brace sequence expression to mess up expansion of an enclosing brace expansion. j. Fixed a bug in command printing that output the wrong default file descriptor for the <> redirection. k. User-specified subshells (`(...)') now update BASH_COMMAND in the subshell. l. Fixed a display bug with the `help -m' and loadable builtins. m. Fixed a potential file descriptor leak when trying to use a pipe for a here document. n. Fix a bug with multiple assignment statements preceding a simple command containing nofork comsubs. o. Fix a potential bug that could result in a NULL buffered stream even with a valid input file descriptor. 2. Changes to Readline a. Fixed a bug that allowed a history search to change the current history list positio
Re: /dev/tcp feature request...
[[ -d /proc/"$!" ]] On Tue, Apr 8, 2025, 16:33 Andreas Schwab wrote: > On Apr 08 2025, MacBeth wrote: > > > while ((dur /dev/null; do > > You can use kill -0 $! to check if the process still exists. > > -- > Andreas Schwab, SUSE Labs, sch...@suse.de > GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 > "And now for something completely different." > >
Re: /dev/tcp feature request...
On Apr 08 2025, MacBeth wrote: > while ((dur /dev/null; do You can use kill -0 $! to check if the process still exists. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different."
Support ksh93 x=${cmd;}
Good morning!
Could bash please support x=${cmd;} alongside x=$(cmd)?
x=$(cmd;} works like x=$(cmd), except that cmd does not run in
a subshell, i.e. the stdout within ${cmd;} is redirected to the
variable "x", but any other changes of variables (global/static/local)
are also available outside ${}, unlike $()
can be anything of blank, tab, newline. The cmd must ALWAYS be
terminated with a ";".
Example:
ksh93 -c 'out_stderr="${ { out_stdout="${ ls x ; (( out_res=$? )) ; }"
; } 2>&1 ; }" ; printf "stdout=%q, stderr=%q, exit code=%d\n"
"$out_stdout" "$out_stderr" "$out_res"'
stdout='', stderr=$'ls: cannot access \'x\': No such file or
directory', exit code=2
Ced
--
Cedric Blancher
[https://plus.google.com/u/0/+CedricBlancher/]
Institute Pasteur
