Re: 3 updates for 5.3rc1

2025-04-10 Thread Chet Ramey 

On 4/6/25 3:16 AM, Duncan Roe wrote:

Hi,

I found the following 3 items. They are addressed by the patch in next email.
Patch is against 2e113467f061587a3475b692d25ca449717834c8 in the devel branch.


Thanks for the message.


1. The new fltexpr loadable builtin doesn't get built.
Need to move it from OTHERPROG to ALLPROG in Makefile.in.


I moved it when I finished adding the math functions to it.


2. `help export` claims that `export -p` prints exported functions.
It does not.


It does, but you have to use -f with it.


3. `help history` fails to document that you can delete a range.


Good catch.

Chet

--
``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/


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Bash skips empty lines when reading history file in multiline mode

2025-04-10 Thread Chet Ramey 

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/


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: 2.0..devel: `set -u; a=1; echo ${#a[@]}' fails

2025-04-10 Thread Chet Ramey 

On 4/7/25 12:36 PM, Koichi Murase wrote:


So to be clear, you're requesting a behavior change so that expanding
${#a[0]}, ${#a[*]}, and ${#a[@]}, where a is a scalar variable, when
nounset is enabled, does not result in an unbound variable error.


Right. That is the behavior I naively expect.


OK, it seems reasonable. I'll look at changing this for the next version.

--
``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/


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: /dev/tcp feature request...

2025-04-10 Thread Chet Ramey 

On 4/7/25 6:24 PM, A. James Lewis wrote:

I've not been around this mailing list all too long, so I don't know if
this has been debated before, but 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.

Is this a feature which might be possible in a future version of Bash?


I'll look at it for a future version. One question: do you think a
connection timeout should be considered a redirection error?

--
``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/


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: /dev/tcp feature request...

2025-04-10 Thread A. James Lewis 
I'm not quite sure about that, I would be trying to get back the file
descriptor to use for a period and then close it... so if it fails to
open, then I don't know if "redirection error" makes sense, but then
again, I'm not sure what would the correct error be.

Certainly I would just be checking for a successful exit code from
opening the connection 

It makes me wonder what the existing error message is, because it
/does/ time out currently... but only after 10 minutes, which I think
is the kernel giving up, and thus forcing the failure.

My use case for reference, is trying to connect to a primary server,
but waiting only 2-5 seconds before giving up and trying a secondary...
as my goal is to achieve a connection as quickly as possible, but
ideally waiting not waiting any longer than 5 seconds if the primary
server is down and I must move on to the secondary.

James


On Thu, 2025-04-10 at 15:14 -0400, Chet Ramey wrote:
> On 4/7/25 6:24 PM, A. James Lewis wrote:
> > I've not been around this mailing list all too long, so I don't
> > know if
> > this has been debated before, but 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.
> > 
> > Is this a feature which might be possible in a future version of
> > Bash?
> 
> I'll look at it for a future version. One question: do you think a
> connection timeout should be considered a redirection error?
> 
> -- 
> ``The lyf so short, the craft so long to lerne.'' - Chaucer
>``Ars longa, vita brevis'' - Hippocrates
> Chet Ramey, UTech, CWRU    c...@case.edu   
> http://tiswww.cwru.edu/~chet/

Re: /dev/tcp feature request...

2025-04-10 Thread Oğuz 
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


-- 
Oğuz

[sr #111224] custom completion not used after escaped semicolon

2025-04-10 Thread anonymous 
URL:
  

 Summary: custom completion not used after escaped semicolon
   Group: The GNU Bourne-Again SHell
   Submitter: None
   Submitted: Thu 10 Apr 2025 10:55:35 PM UTC
Category: None
Priority: 5 - Normal
Severity: 2 - Minor
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: da...@mandelberg.org
 Open/Closed: Open
 Discussion Lock: Any
Operating System: GNU/Linux


___

Follow-up Comments:


---
Date: Thu 10 Apr 2025 10:55:35 PM UTC By: Anonymous
Given this function with completion:


$ LC_ALL=C bash --norc
bash-5.2$ f() { :; } && complete -A user f


Pressing tab at the end of this line completes to root as expected:


bash-5.2$ f abc ro


But this does not offer any completions, even though the backslash is
escaped:


bash-5.2$ f \; ro


This completes to /dev/null:


bash-5.2$ f \; /dev/nu









___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/


signature.asc
Description: PGP signature

Make cd built-in as resilient as mkdir -p built-in

2025-04-10 Thread Laurent Lyaudet 
Hello :),

Recently, I noticed during tests that mkdir -p can handle paths beyond
PATH_MAX that is currently 4096.
But cd cannot do this.
You have to split your cd commands to go to the farthest directory.

I think that cd cannot move if it fails.
In case of error, it must keep bash in the same current directory.
Maybe I'm wrong.

But if I'm wrong and that is not a requirement,
then splitting the path before recursive calls of one level depth cd would
make cd as resilient as mkdir -p.
If I'm not wrong, we need to handle some kind of backtracking in cd.
I hope this is something that can be done.
I will not argue further if it's not accepted here.

***Below greetings is some sample script to demonstrate/reproduce the
"bug/more resilient feature request"***
(For reference, here is where this problem comes out:
https://discourse.ubuntu.com/t/increasing-path-max-to-8092-and-name-max-to-512/58748/20?u=laurent-lyaudet
)

Best regards,
Laurent Lyaudet

#!/bin/bash

# base 16, each lines count for 64, 64*64=4096
mkdir -p 0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
0123456789012345/0123456789012345/0123456789012

Re: Make cd built-in as resilient as mkdir -p built-in

2025-04-10 Thread Laurent Lyaudet 
Le jeu. 10 avr. 2025 à 18:30, Laurent Lyaudet  a
écrit :

>
>
> Le jeu. 10 avr. 2025 à 18:29, Laurent Lyaudet 
> a écrit :
>
>> Hello :),
>>
>> Recently, I noticed during tests that mkdir -p can handle paths beyond
>> PATH_MAX that is currently 4096.
>> But cd cannot do this.
>> You have to split your cd commands to go to the farthest directory.
>>
>> I think that cd cannot move if it fails.
>> In case of error, it must keep bash in the same current directory.
>> Maybe I'm wrong.
>>
>> But if I'm wrong and that is not a requirement,
>> then splitting the path before recursive calls of one level depth cd
>> would make cd as resilient as mkdir -p.
>> If I'm not wrong, we need to handle some kind of backtracking in cd.
>> I hope this is something that can be done.
>> I will not argue further if it's not accepted here.
>>
>> ***Below greetings is some sample script to demonstrate/reproduce the
>> "bug/more resilient feature request"***
>> (For reference, here is where this problem comes out:
>>
>> https://discourse.ubuntu.com/t/increasing-path-max-to-8092-and-name-max-to-512/58748/20?u=laurent-lyaudet
>> )
>>
>> Best regards,
>> Laurent Lyaudet
>>
>> #!/bin/bash
>>
>> # base 16, each lines count for 64, 64*64=4096
>> mkdir -p 
>> 0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
>> 0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
>> 0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
>> 0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
>> 0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
>> 0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
>> 0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
>> 0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
>> 0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
>> 0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
>> 0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
>> 0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
>> 0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
>> 0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
>> 0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
>> 0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
>> 0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
>> 0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
>> 0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
>> 0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
>> 0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
>> 0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
>> 0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
>> 0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
>> 0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
>> 0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
>> 0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
>> 0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
>> 0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
>> 0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
>> 0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
>> 0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
>> 0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
>> 0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
>> 0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
>> 0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
>> 0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
>> 0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
>> 0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
>> 0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
>> 0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
>> 0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
>> 0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
>> 0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
>> 0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
>> 0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
>> 0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
>> 0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
>> 0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
>> 0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
>> 0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
>> 0123456789012345/012345678

Re: Make cd built-in as resilient as mkdir -p built-in

2025-04-10 Thread Laurent Lyaudet 
Le jeu. 10 avr. 2025 à 18:29, Laurent Lyaudet  a
écrit :

> Hello :),
>
> Recently, I noticed during tests that mkdir -p can handle paths beyond
> PATH_MAX that is currently 4096.
> But cd cannot do this.
> You have to split your cd commands to go to the farthest directory.
>
> I think that cd cannot move if it fails.
> In case of error, it must keep bash in the same current directory.
> Maybe I'm wrong.
>
> But if I'm wrong and that is not a requirement,
> then splitting the path before recursive calls of one level depth cd would
> make cd as resilient as mkdir -p.
> If I'm not wrong, we need to handle some kind of backtracking in cd.
> I hope this is something that can be done.
> I will not argue further if it's not accepted here.
>
> ***Below greetings is some sample script to demonstrate/reproduce the
> "bug/more resilient feature request"***
> (For reference, here is where this problem comes out:
>
> https://discourse.ubuntu.com/t/increasing-path-max-to-8092-and-name-max-to-512/58748/20?u=laurent-lyaudet
> )
>
> Best regards,
> Laurent Lyaudet
>
> #!/bin/bash
>
> # base 16, each lines count for 64, 64*64=4096
> mkdir -p 0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
> 0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
> 0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
> 0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
> 0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
> 0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
> 0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
> 0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
> 0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
> 0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
> 0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
> 0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
> 0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
> 0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
> 0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
> 0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
> 0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
> 0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
> 0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
> 0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
> 0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
> 0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
> 0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
> 0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
> 0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
> 0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
> 0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
> 0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
> 0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
> 0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
> 0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
> 0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
> 0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
> 0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
> 0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
> 0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
> 0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
> 0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
> 0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
> 0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
> 0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
> 0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
> 0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
> 0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
> 0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
> 0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
> 0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
> 0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
> 0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
> 0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
> 0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
> 0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
> 0123456789012345/0123456789012345/0123456789012345/0123456789012345/\
> 0123456789012345/0123456789012345/01