Re: Bash skips empty lines when reading history file in multiline mode
On 2025-04-07 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. Right, the lithist option has nothing to do with this problem, I think that was more of a left-over from writing up the test case than anything else. > But do you really think people want blank history entries even with lithist > set? No. Also the leading and trailing blank lines in my example were there just to ensure that my patch works also in these edge cases. In reality Bash does not really need to preserve these, IMO. > How about history processing blank lines as part of the command after > it reads the first non-blank line? Sounds like a good compromise between complexity of implementation and blank line preservance in the result. Thanks!
/dev/tcp feature request...
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 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. -- A. James Lewis
Re: Bash skips empty lines when reading history file in multiline mode
one small addition , <<'foo' ( with quotes is used ) .. .. should tell bash expliciply preserve data .. On Mon, Apr 7, 2025, 23:51 microsuxx wrote: > 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: 2.0..devel: `set -u; a=1; echo ${#a[@]}' fails
Thank you for your answer.
2025年4月8日(火) 0:40 Chet Ramey :
> OK, so you're asking for a new feature/behavior change.
Yes.
> don't get me wrong, but it's a little late in the cycle for bash-5.3.
Yeah, that makes sense. I don't mind if the change would be applied in
a later version.
> > I'd be happy if the current behavior is fixed.
>
> 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.
--
Koichi
Re: 2.0..devel: `set -u; a=1; echo ${#a[@]}' fails
On 4/5/25 5:37 PM, Koichi Murase wrote:
With nounset, ${#a[@]} for a scalar variable fails even though we can
correctly obtain the result (which is consistent with the expansion of
"${a[@]}") without nounset. This is the result with the devel
version:
$ bash -c 'a=1; echo ${#a[@]}'
1
$ bash -uc 'a=1; echo ${#a[@]}'
bash: line 1: a: unbound variable
This behavior seems to be present from the very beginning
implementation of arrays in bash-2.0:
OK, so you're asking for a new feature/behavior change. Which is fine,
don't get me wrong, but it's a little late in the cycle for bash-5.3.
However, this behavior does not match that of other shells:
OK.
Is this intentional?
Maybe? That was more than 30 years ago.
I'd be happy if the current behavior is fixed.
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.
--
``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
