Re: /dev/tcp feature request...

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 f

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

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: Non

Re: /dev/tcp feature request...

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

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

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 cann

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

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 y

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

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 cur

Re: /dev/tcp feature request...

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 m

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

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.

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

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.

Re: 3 updates for 5.3rc1

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