Re: Support ksh93 x=${cmd;}
On Wed, 9 Apr 2025 at 15:16, Chet Ramey wrote:
>
> On 4/9/25 2:09 AM, Cedric Blancher wrote:
> > Good morning!
> >
> > Could bash please support x=${cmd;} alongside x=$(cmd)?
>
> I implemented it back in 2023 and it will be in bash-5.3.
Thank you.
I like the x=${ cmd;} feature :)
Dan
--
Dan Shelton - Cluster Specialist Win/Lin/Bsd
Re: Support ksh93 x=${cmd;}
On Wed, 9 Apr 2025 at 15:16, Chet Ramey wrote:
>
> On 4/9/25 2:09 AM, Cedric Blancher wrote:
> > Good morning!
> >
> > Could bash please support x=${cmd;} alongside x=$(cmd)?
>
> I implemented it back in 2023 and it will be in bash-5.3.
>
> There was quite a long discussion about it:
>
> https://lists.gnu.org/archive/html/bug-bash/2023-05/msg00042.html
I don't like the x=${| ,,,} form. HP/UX had a crazy /bin/sh extension
for some time to read pipe input for the "..." cmd, but it was so
buggy that it was infamous with support staff.
Docs should clarify that this is NOT the HP/UX madness
Dan
--
Dan Shelton - Cluster Specialist Win/Lin/Bsd
Re: Support ksh93 x=${cmd;}
Besides, HP-UX sh is ksh88 :-) no risk anyone port anything from there.
Re: Support ksh93 x=${cmd;}
On 4/9/25 2:09 AM, Cedric Blancher wrote:
Good morning!
Could bash please support x=${cmd;} alongside x=$(cmd)?
I implemented it back in 2023 and it will be in bash-5.3.
There was quite a long discussion about it:
https://lists.gnu.org/archive/html/bug-bash/2023-05/msg00042.html
--
``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;}
On 4/9/25 9:46 AM, Dan Shelton wrote:
What is not great is the cmd | x=${|cmd;} extension in HP/UX which
randomly hung or crashed /bin/sh in a way to make the tty locked and
unuseable.
Sure, I get that. I wager that there are comparatively few people who
will assume this is an implementation of that HP/UX (mis)feature.
But maybe before asking for documentation clarifications to call out
that it's *not* some short-lived obscure historical feature, take a look
at the documentation currently describing it and see if it's clear
enough.
--
``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;}
On 4/9/25 9:31 AM, Dan Shelton wrote:
On Wed, 9 Apr 2025 at 15:16, Chet Ramey wrote:
On 4/9/25 2:09 AM, Cedric Blancher wrote:
Good morning!
Could bash please support x=${cmd;} alongside x=$(cmd)?
I implemented it back in 2023 and it will be in bash-5.3.
There was quite a long discussion about it:
https://lists.gnu.org/archive/html/bug-bash/2023-05/msg00042.html
I don't like the x=${| ,,,} form. HP/UX had a crazy /bin/sh extension
for some time to read pipe input for the "..." cmd, but it was so
buggy that it was infamous with support staff.
Docs should clarify that this is NOT the HP/UX madness
Why not read the documentation describing it first?
--
``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: Bash skips empty lines when reading history file in multiline mode
i dunno what lithist is , but remaining data one to one is a big bug thats gotta be fixed its like u write foo "$1" "$2" and it sends foo $1 $2 .. if data , in case heredoc content , which is highly underrated and underused , is not remained .. its nothing else than a big broken cmd plz fixx greets++ ur microsucker .. On Mon, Apr 7, 2025, 22:34 Chet Ramey wrote: > On 4/4/25 4:18 PM, Jens Schmidt wrote: > > > [bashbug output manually adapted to real version ...] > > Bash Version: 5.3 > > Commit: a6767763de5e7859107711b166a64a9e4a77a8ae > > Release Status: compiled from recent devel branch > > > > > > Description: > >Bash skips empty lines when reading history file in multiline mode. > > This is a problem even if lithist isn't set -- it's not uncommon to have > blank lines in here-documents. > > But do you really think people want blank history entries even with lithist > set? How about history processing blank lines as part of the command after > it reads the first non-blank line? > > -- > ``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;}
On Wed, 9 Apr 2025 at 15:40, Chet Ramey wrote:
>
> On 4/9/25 9:31 AM, Dan Shelton wrote:
> > On Wed, 9 Apr 2025 at 15:16, Chet Ramey wrote:
> >>
> >> On 4/9/25 2:09 AM, Cedric Blancher wrote:
> >>> Good morning!
> >>>
> >>> Could bash please support x=${cmd;} alongside x=$(cmd)?
> >>
> >> I implemented it back in 2023 and it will be in bash-5.3.
> >>
> >> There was quite a long discussion about it:
> >>
> >> https://lists.gnu.org/archive/html/bug-bash/2023-05/msg00042.html
> >
> > I don't like the x=${| ,,,} form. HP/UX had a crazy /bin/sh extension
> > for some time to read pipe input for the "..." cmd, but it was so
> > buggy that it was infamous with support staff.
> >
> > Docs should clarify that this is NOT the HP/UX madness
>
> Why not read the documentation describing it first?
Clarification:
bash and ksh93 x=${ cmd;} is great!!!
What is not great is the cmd | x=${|cmd;} extension in HP/UX which
randomly hung or crashed /bin/sh in a way to make the tty locked and
unuseable. People who remember the HP/UX /bin/sh extension will suffer
from PTSD if they see that syntax, esp university admins where
students used this as "sport" to take down machines. HP fortunately
removed their HP/UX /bin/sh extension very fast.
Dan
--
Dan Shelton - Cluster Specialist Win/Lin/Bsd
Re: /dev/tcp feature request...
Yes, this is how I am doing it currently, but remember that once you
cut that subshell loose, you cannot easily get a response from it and
certainly can't pass variables back... and you are more or less forced
to wait for a sensible timeout, even tho the actual connection might
take a much shorter time.
It also makes it extremely complex compared to a simple timeout
feature, where multiple data could be returned from the function in a
shorter time, and the file descriptor preserved for reuse after some of
that data is processed.
I do appreciate that these workarounds exist, but they are complex, and
limiting, compared to a simple TCP_TMOUT parameter or similar used
similarly to "IFS"... which would make this a much more usable tool.
James
On Tue, 2025-04-08 at 08:54 -0500, 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.
> >
>
> 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... :/
