Date:Thu, 12 Oct 2023 21:36:48 -0700
From:Grisha Levit
Message-ID:
| There are some issues with parser output when the input has an unquoted
| backslash followed by a raw ^A character:
The NetBSD shell (and probably other ash derived shells) used to
have issues
Date:Thu, 12 Oct 2023 16:11:09 -0700
From:Grisha Levit
Message-ID:
| If we want to preserve the behavior of unquoted backslash
| causing a following
| quoted character to become unquoted after quote_string_for_globbing:
Please don't. Something explicity quo
There are some issues with parser output when the input has an unquoted
backslash followed by a raw ^A character:
$ bash -c $'echo ${_+\\\1}' |& cat -v
bash: line 1: bad substitution: no closing `}' in ${_+\^A^A}
$ bash -c $'[[ \1 =~ (\\\1) ]]' |& cat -v
bash: line 1: [[: invalid regular expressi
Handle $'\c^A' and $'\c^?' correctly when expanded by the parser:
$ bash -c $'printf "%q\n" $\'\\c\001 \\c\177\''
$'\001\001 \001\177'
---
diff --git a/lib/sh/strtrans.c b/lib/sh/strtrans.c
index d3b27f3b..3df33ade 100644
--- a/lib/sh/strtrans.c
+++ b/lib/sh/strtrans.c
@@ -198,6 +198,8 @@ ansicst
On Sat, Oct 7, 2023 at 9:57 AM Chet Ramey wrote:
>
> On 9/26/23 2:25 AM, Grisha Levit wrote:
> > A CTLESC-escaped character should be treated as such even if it follows an
> > unquoted backslash, same as in quote_string_for_globbing:
>
> Thanks for the report and patch.
Sorry I guess this part wa
On 10/12/23 6:18 AM, Bodo Thiesen wrote:
Hello list.
The following script can be used to reproduce the problem. It seems to be
related to sub-processes terminating at the "wrong" moment. The symptom:
The script runs for some time counting up until at some moment the script
hangs in the read func
Hello list.
The following script can be used to reproduce the problem. It seems to be
related to sub-processes terminating at the "wrong" moment. The symptom:
The script runs for some time counting up until at some moment the script
hangs in the read function. Once this happens, the timeout is no
