Re: 5.3-alpha: less readable output when set -x
> This is from https://lists.gnu.org/archive/html/bug-bash/2023-06/msg00092.htm > l > > It ensures e.g. that control characters are always displayed in a > printable manner. so that is definitely intentional and everything is now clear to me thanks a lot for your time ciao -gabriele
Re: 5.3-alpha: less readable output when set -x
On 4/24/24 11:34 AM, baldu...@units.it wrote: Note the difference in how the argument to the function is output. In the case of bash-5.3-alpha the syntax of the argument is correct (ie if I call the show function with $'\n1\n2\n3\n' everything works as expected), but is less readable (and this is more so if the argument is a long stretch of lines) For what I seem to understand, this might be related to: 8< b. Bash does a better job of preserving user-supplied quotes around a word completion, instead of requoting it. >8 That's not it. It's sort of bundled together with a note about other quoting changes. I can add a separate item to CHANGES if you think it would be worthwhile. Of course, if the "new" behavior is intentional, I guess there will be good reasons for it and apologize for the noise Grisha, unsurprisingly, identified the original report from June, 2023 that prompted the change. 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/
Re: 5.3-alpha: less readable output when set -x
On Wed, Apr 24, 2024 at 11:35 AM wrote: > > hello > > Apologies if I am missing some blatant point here > > I have noticed a difference in behavior of bash-5.2.26 and > bash-5.3-alpha which isn't a problem of correctness, but may be wasn't > intentional(?) This is from https://lists.gnu.org/archive/html/bug-bash/2023-06/msg00092.html It ensures e.g. that control characters are always displayed in a printable manner.
Re: 5.3-alpha: less readable output when set -x
On Wed, 24 Apr 2024, at 4:34 PM, baldu...@units.it wrote:
> hello
>
> Apologies if I am missing some blatant point here
>
> I have noticed a difference in behavior of bash-5.2.26 and
> bash-5.3-alpha which isn't a problem of correctness, but may be wasn't
> intentional(?)
>
> Given the scriptlett:
>
> 8<
> #!/bin/sh
> set -x
>
> show () {
> cat < $1
> EOF
> return 0
> }
>
> show "
> 1
> 2
> 3
> "
> exit 0
> 8<
>
> for me the output is different for the 2 versions:
>
> bash-5.2.26 :bash-5.3-alpha :
> 8< 8<
> ##> ./scriptlett.sh ##> ./scriptlett.sh
> + show ' + show $'\n1\n2\n3\n'
> 1+ cat
> 2
> 31
> '2
> + cat3
>
> 1+ return 0
> 2+ exit 0
> 3>8
>
> + return 0
> + exit 0
> >8
>
> Note the difference in how the argument to the function is
> output. In the case of bash-5.3-alpha the syntax of the argument is
> correct (ie if I call the show function with $'\n1\n2\n3\n' everything
> works as expected), but is less readable (and this is more so if the
> argument is a long stretch of lines)
>
> For what I seem to understand, this might be related to:
>
> 8<
> b. Bash does a better job of preserving user-supplied quotes around a word
> completion, instead of requoting it.
> >8
> ?
I don't think so. That appears to be referring to the behaviour of readline
completion in an interactive shell.
>
> Of course, if the "new" behavior is intentional, I guess there will be
> good reasons for it and apologize for the noise
It's an interesting observation. I have noticed lately that bash has started to
become more consistent in its quoting strategies. For instance, 5.2 changed the
behaviour of declare -p, such that it sometimes employs a quoting strategy like
that of the ${param@Q} form of expansion.
$ var1=$'foo\nbar' var2=$'foo\rbar'
$ declare -p BASH_VERSION var1 var2
declare -- BASH_VERSION="5.2.26(1)-release"
declare -- var1=$'foo\nbar'
declare -- var2=$'foo\rbar'
$ var1=$'foo\nbar' var2=$'foo\rbar'
$ declare -p BASH_VERSION var1 var2
declare -- BASH_VERSION="5.1.16(1)-release"
declare -- var1="foo
bar"
bar"are -- var2="foo
In my opinion, that demonstrates that the new approach is obviously superior.
That is, the output of 5.2 there is vastly more legible to me; to make sense of
the output of 5.1, I might have to rely on a utility such as od or hexdump. Put
another way, this style of quoting is tremendously helpful for conveying
strings that do not exclusively consist of graphemes.
Anyway, it look as though the xtrace mode has been similar adjusted.
--
Kerin Millar
5.3-alpha: less readable output when set -x
hello
Apologies if I am missing some blatant point here
I have noticed a difference in behavior of bash-5.2.26 and
bash-5.3-alpha which isn't a problem of correctness, but may be wasn't
intentional(?)
Given the scriptlett:
8<
#!/bin/sh
set -x
show () {
cat < ./scriptlett.sh ##> ./scriptlett.sh
+ show ' + show $'\n1\n2\n3\n'
1+ cat
2
31
'2
+ cat3
1+ return 0
2+ exit 0
3>8
+ return 0
+ exit 0
>8
Note the difference in how the argument to the function is
output. In the case of bash-5.3-alpha the syntax of the argument is
correct (ie if I call the show function with $'\n1\n2\n3\n' everything
works as expected), but is less readable (and this is more so if the
argument is a long stretch of lines)
For what I seem to understand, this might be related to:
8<
b. Bash does a better job of preserving user-supplied quotes around a word
completion, instead of requoting it.
>8
?
Of course, if the "new" behavior is intentional, I guess there will be
good reasons for it and apologize for the noise
Just noticed and thought it was good to report upstream
thanks a lot for your valuable work
ciao
-gabriele
Re: [PATCH] fix [[ -t X ]] segfault
On 9/8/23 12:36 PM, Grisha Levit wrote: Since the change that made `test -t FD' report an error for non-numeric values of FD: $ [[ -t X ]] bash: [[: X: integer expected Segmentation fault Thanks for the report and patch. 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/
[PATCH] fix [[ -t X ]] segfault
Since the change that made `test -t FD' report an error for non-numeric
values of FD:
$ [[ -t X ]]
bash: [[: X: integer expected
Segmentation fault
Below patch wraps all [[ test execution in a new function that provides
a jump target and returns an exit status usable directly by the
cond_node code -- so the above now has an exit status of 2 like the test
builtin.
From 6e5be14727843d441f7c69a6e49473eabf049a9a Mon Sep 17 00:00:00 2001
From: Grisha Levit
Date: Fri, 8 Sep 2023 11:10:16 -0400
Subject: [PATCH] fix [[ -t X ]] segfault
Since the change that made `test -t FD' report an error for non-numeric
values of FD:
$ [[ -t X ]]
bash: [[: X: integer expected
Segmentation fault
Below patch wraps all [[ test execution in a new function that provides
a jump target and returns an exit status usable directly by the
cond_node code -- so the above now has an exit status of 2 like the test
builtin.
---
execute_cmd.c | 6 ++
test.c| 25 +++--
test.h| 3 +--
3 files changed, 26 insertions(+), 8 deletions(-)
diff --git a/execute_cmd.c b/execute_cmd.c
index 2c99493b..6cbb00df 100644
--- a/execute_cmd.c
+++ b/execute_cmd.c
@@ -3942,7 +3942,7 @@ execute_cond_node (COND_COM *cond)
if (varop)
oa = set_expand_once (0, 0); /* no-op for compatibility levels <= 51 */
#endif
- result = unary_test (cond->op->word, arg1, varflag) ? EXECUTION_SUCCESS : EXECUTION_FAILURE;
+ result = test_run_test (cond->op->word, arg1, NULL, varflag);
#if defined (ARRAY_VARS)
if (varop)
array_expand_once = oa;
@@ -4022,9 +4022,7 @@ execute_cond_node (COND_COM *cond)
#endif /* COND_REGEXP */
{
extended_glob = 1;
- result = binary_test (cond->op->word, arg1, arg2, TEST_PATMATCH|TEST_ARITHEXP|TEST_LOCALE)
- ? EXECUTION_SUCCESS
- : EXECUTION_FAILURE;
+ result = test_run_test (cond->op->word, arg1, arg2, TEST_PATMATCH|TEST_ARITHEXP|TEST_LOCALE);
extended_glob = extglob_flag;
}
if (arg1 != nullstr)
diff --git a/test.c b/test.c
index aa01926c..d3906c6e 100644
--- a/test.c
+++ b/test.c
@@ -118,6 +118,9 @@ static void test_syntax_error (char *, char *) __attribute__((__noreturn__));
static void beyond (void) __attribute__((__noreturn__));
static void integer_expected_error (char *) __attribute__((__noreturn__));
+static int unary_test (char *, char *, int);
+static int binary_test (char *, char *, char *, int);
+
static int unary_operator (void);
static int binary_operator (void);
static int two_arguments (void);
@@ -376,7 +379,7 @@ patcomp (char *string, char *pat, int op)
return ((op == EQ) ? (m == 0) : (m != 0));
}
-int
+static int
binary_test (char *op, char *arg1, char *arg2, int flags)
{
int patmatch;
@@ -509,7 +512,7 @@ unary_operator (void)
return (unary_test (op, argv[pos - 1], 0));
}
-int
+static int
unary_test (char *op, char *arg, int flags)
{
intmax_t r;
@@ -857,6 +860,24 @@ posixtest (void)
return (value);
}
+/* If ARG2 is not NULL, dispatch a binary test, otherwise a unary test.
+ For use by execute_cond_node. */
+int
+test_run_test (char *op, char *arg1, char *arg2, int flags)
+{
+ int code, ret;
+
+ code = setjmp_nosigs (test_exit_buf);
+
+ if (code)
+return test_error_return;
+
+ ret = arg2 ? binary_test (op, arg1, arg2, flags)
+ : unary_test (op, arg1, flags);
+
+ return (ret ? EXECUTION_SUCCESS : EXECUTION_FAILURE);
+}
+
/*
* [:
* '[' expr ']'
diff --git a/test.h b/test.h
index 2a816892..aa04c7a7 100644
--- a/test.h
+++ b/test.h
@@ -32,8 +32,7 @@
extern int test_unop (char *);
extern int test_binop (char *);
-extern int unary_test (char *, char *, int);
-extern int binary_test (char *, char *, char *, int);
+extern int test_run_test (char *, char *, char *, int);
extern int test_command (int, char **);
--
2.42.0
Re: key "x" doesn't print out the "x", only "CTRL-V x" does.
On 9/7/23 8:17 AM, detlef.bier...@posteo.de wrote: Bash Version: 5.1 Patch Level: 16 Release Status: release Description: When pressing the "x" key, no letter appears, with the combination "CTRL-v x" the "x" appears. The key only works in bash, in sh, in the X server as well, in all graphic applications as well, as well as in the editors nano, joe, etc. If this works, please send me the instructions. THANKS! You have `x' bound to a readline command other than self-insert, or you have it bound to one of the stty special characters. Check the first by looking at the output of bind -p | grep '^\"x"'; check the second by looking at the output of `stty -a'. -- ``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/
key "x" doesn't print out the "x", only "CTRL-V x" does.
Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -g -O2 -flto=auto -ffat-lto-objects -flto=auto -ffat-lto-objects -fstack-protector-strong -Wformat -Werror=format-security -Wall uname output: Linux db2 5.15.0-83-generic #92-Ubuntu SMP Mon Aug 14 09:30:42 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux Machine Type: x86_64-pc-linux-gnu Bash Version: 5.1 Patch Level: 16 Release Status: release Description: When pressing the "x" key, no letter appears, with the combination "CTRL-v x" the "x" appears. The key only works in bash, in sh, in the X server as well, in all graphic applications as well, as well as in the editors nano, joe, etc. If this works, please send me the instructions. THANKS! (translation by google)
Re: set -x vs. n=($@)
OK. That's well and good. But my main problem now is that that fact is not documented anywhere. (Also here it is again, so as to remove any confusion about "compound assignment" (some readers might think it meant two ='s on the same line.) $ bash -c 'set a b c; set -x; m=$@; n=($@)' + m='a b c' + n=($@) ) >>>>> "CR" == Chet Ramey writes: CR> On 9/3/23 6:08 AM, Dan Jacobson wrote: >> It's not fair: >> set -x a b c >> m=$@ n=($@) >> == gives == >> + m='a b c' >> + n=($@) CR> It's because the compound assignment forces the expansion to be deferred. CR> You have to figure out what kind of array you're dealing with, for example, CR> and what kind of compound assignment, and bash figures all that out after CR> the `we're performing a variable assignment with xtrace enabled, print the CR> rhs' code runs.
Re: set -x vs. n=($@)
On 9/3/23 6:08 AM, Dan Jacobson wrote: It's not fair: set -x a b c m=$@ n=($@) == gives == + m='a b c' + n=($@) It's because the compound assignment forces the expansion to be deferred. You have to figure out what kind of array you're dealing with, for example, and what kind of compound assignment, and bash figures all that out after the `we're performing a variable assignment with xtrace enabled, print the rhs' code runs. -- ``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: set -x vs. n=($@)
On 9/3/23 12:15 PM, Lawrence Velázquez wrote:
However...
bash-5.2$ declare -a c=("$a")
+ c=('foo')
+ declare -a c
You kind of have to. This isn't an assignment statement, since `declare'
is a builtin and its arguments have to be expanded before it's called and
set -x kicks in. The fact that it's an assignment builtin complicates
things.
--
``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: set -x vs. n=($@)
On Sun, Sep 3, 2023, 20:57 Greg Wooledge wrote: > On Sun, Sep 03, 2023 at 08:39:25PM +0200, alex xmb ratchev wrote: > > On Sun, Sep 3, 2023, 12:08 Dan Jacobson wrote: > > > > > It's not fair: > > > set -x a b c > > > > > > > you may want -v > > *Sigh* No. set -v shows lines as they are being READ by the shell. > set -x shows commands as they are being EXECUTED. > > set -v is almost never useful. It's especially unlikely to be useful > in any script that uses functions or loops, as it only shows the function > or the loop being READ, not being EXECUTED. > sorry ye , i had success with ' : $vars .. ' but thats not so good for var assign peace >
Re: set -x vs. n=($@)
On Sun, Sep 03, 2023 at 08:39:25PM +0200, alex xmb ratchev wrote: > On Sun, Sep 3, 2023, 12:08 Dan Jacobson wrote: > > > It's not fair: > > set -x a b c > > > > you may want -v *Sigh* No. set -v shows lines as they are being READ by the shell. set -x shows commands as they are being EXECUTED. set -v is almost never useful. It's especially unlikely to be useful in any script that uses functions or loops, as it only shows the function or the loop being READ, not being EXECUTED.
Re: set -x vs. n=($@)
On Sun, Sep 3, 2023, 12:08 Dan Jacobson wrote:
> It's not fair:
> set -x a b c
>
you may want -v
m=$@ n=($@)
> == gives ==
> + m='a b c'
> + n=($@)
> please either say
> + m=$@
> + n=($@)
> or better:
> + m='a b c'
> + n=('a' 'b' 'c')
> or metion on
> https://www.gnu.org/software/bash/manual/html_node/The-Set-Builtin.html
> the special exception.
> GNU bash, version 5.2.15
>
>
Re: set -x vs. n=($@)
On Sun, Sep 3, 2023, at 6:08 AM, Dan Jacobson wrote:
> please either say
> + m=$@
> + n=($@)
> or better:
> + m='a b c'
> + n=('a' 'b' 'c')
> or metion on
> https://www.gnu.org/software/bash/manual/html_node/The-Set-Builtin.html
> the special exception.
This behavior is not specific to $@.
bash-5.2$ a=foo
bash-5.2$ set -x
bash-5.2$ b=("$a")
+ b=("$a")
However...
bash-5.2$ declare -a c=("$a")
+ c=('foo')
+ declare -a c
--
vq
set -x vs. n=($@)
It's not fair:
set -x a b c
m=$@ n=($@)
== gives ==
+ m='a b c'
+ n=($@)
please either say
+ m=$@
+ n=($@)
or better:
+ m='a b c'
+ n=('a' 'b' 'c')
or metion on
https://www.gnu.org/software/bash/manual/html_node/The-Set-Builtin.html the
special exception.
GNU bash, version 5.2.15
Re: [PATCH] fix bind -X quoting
On 7/31/23 11:51 AM, G. Branden Robinson wrote:
At 2023-07-31T09:30:30-0400, Chet Ramey wrote:
Rather than embed more and more shell-specific output formats that
readline doesn't parse into readline itself, I'm more inclined to add
a hook to allow an application to print the value of a key binding
itself.
[...]
This would allow us, for instance, to really go wild and make `bind
-X' display a series of `bind -x' commands to recreate the macro
bindings.
I'm unlikely to be doing any of the work, but big +1 on this. This
would be a valuable inspection and troubleshooting tool. ("What does
bash _think_ I've got bound to this?")
`bind -X' already displays the key sequence and value, just without the
leading `bind -x' to make it really reusable. The default macro printer
displays macro bindings in a way that allows you to put them into an
inputrc file, but you're not doing that with `bind -x' anyway.
--
``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: [PATCH] fix bind -X quoting
At 2023-07-31T09:30:30-0400, Chet Ramey wrote:
> Rather than embed more and more shell-specific output formats that
> readline doesn't parse into readline itself, I'm more inclined to add
> a hook to allow an application to print the value of a key binding
> itself.
[...]
> This would allow us, for instance, to really go wild and make `bind
> -X' display a series of `bind -x' commands to recreate the macro
> bindings.
I'm unlikely to be doing any of the work, but big +1 on this. This
would be a valuable inspection and troubleshooting tool. ("What does
bash _think_ I've got bound to this?")
Regards,
Branden
signature.asc
Description: PGP signature
Re: [PATCH] fix bind -X quoting
On 7/31/23 9:30 AM, Chet Ramey wrote: On 7/26/23 5:57 PM, Grisha Levit wrote: It's just not transitive. Another issue I didn't think of with printing the unquoted translated command is that it can include newlines, which is a problem since you have to read the `bind -X' output one line at a time to reuse it with `bind -x'. If there isn't a backwards compatible way to produce output that is reusable given the current input format, I wonder if we can leverage a format that's not currently valid as input. Rather than embed more and more shell-specific output formats that readline doesn't parse into readline itself, I'm more inclined to add a hook to allow an application to print the value of a key binding itself. I don't know if it makes sense to let the application display anything but macro values, but something like typedef void rl_macro_display_hook (const char *kseq, const char *value, int ptype); So you end up with typedef void rl_macro_print_func_t (const char *, const char *, int); rl_macro_print_func_t *rl_macro_display_hook = (rl_macro_print_func_t *)NULL; and have rl_macro_dumper call (*rl_macro_display_hook) (keyname, (const char *)map[key].function, print_readably); if it's non-NULL, and let the hook function determine how to print the binding. -- ``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: [PATCH] fix bind -X quoting
On 7/26/23 5:57 PM, Grisha Levit wrote: It's just not transitive. Another issue I didn't think of with printing the unquoted translated command is that it can include newlines, which is a problem since you have to read the `bind -X' output one line at a time to reuse it with `bind -x'. If there isn't a backwards compatible way to produce output that is reusable given the current input format, I wonder if we can leverage a format that's not currently valid as input. Rather than embed more and more shell-specific output formats that readline doesn't parse into readline itself, I'm more inclined to add a hook to allow an application to print the value of a key binding itself. I don't know if it makes sense to let the application display anything but macro values, but something like typedef void rl_macro_display_hook (const char *kseq, const char *value, int ptype); where kseq is the key sequence, value is the `raw' macro value, and ptype is a flag saying whether or not to print in a reusable way would be a start at printing macro values. It's backwards compatible with other versions of readline, since we're adding to the API and no application will have this variable set currently. This would allow us, for instance, to really go wild and make `bind -X' display a series of `bind -x' commands to recreate the macro bindings. That would also allow your proposal to have the display hook to use whitespace separators with only `bind -x' having to understand how to read them. -- ``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: [PATCH] fix bind -X quoting
On Wed, Jul 26, 2023, 16:06 Chet Ramey wrote:
>
> On 7/24/23 1:13 PM, Chet Ramey wrote:
>
> > You could do it if you allowed, say
> >
> > bind -x '"\eX": \"command with spaces\" \"x\"'
> >
> > and then stripped the backslashes before calling rl_generic_bind, but
> > that's not exactly backwards compatible either.
>
> Thinking about it some more, you can do it like this:
>
> bind -x $'"\\eX": \'"command with spaces" "x"\''
>
> since bind -x allows single-quoted strings as the command to execute,
> and $'...' allows backslash-escaped single quotes.
>
> If we ran the command string through rl_translate_keyseq, it would allow
> backslash-escaped double quotes and strip the backslashes, but you get
> the rest of the backslash processing that you probably don't want.
>
> It's just not transitive.
Another issue I didn't think of with printing the unquoted translated
command is that it can include newlines, which is a problem since you
have to read the `bind -X' output one line at a time to reuse it with
`bind -x'.
If there isn't a backwards compatible way to produce output that is
reusable given the current input format, I wonder if we can leverage a
format that's not currently valid as input. `bind -x' currently
requires a colon following the key sequence but we could change it to
also allow input without it and use rl_macro_bind instead of
rl_generic_bind if we get such input. If we have `bind -X' produce
untranslated output as it did before, but without the `:', everything
should match up and existing valid `bind -X' commands will be
unaffected.
---
diff --git a/bashline.c b/bashline.c
index 5dac2e9e..9d99c536 100644
--- a/bashline.c
+++ b/bashline.c
@@ -4702,7 +4702,7 @@ bind_keyseq_to_unix_command (char *line)
{
Keymap kmap, cmd_xmap;
char *kseq, *value;
- int i, kstart;
+ int i, kstart, translate;
kmap = rl_get_keymap ();
@@ -4716,16 +4716,13 @@ bind_keyseq_to_unix_command (char *line)
/* Create the key sequence string to pass to rl_generic_bind */
kseq = substring (line, kstart, i);
- for ( ; line[i] && line[i] != ':'; i++)
+ /* Advance to the colon (:) or whitespace which separates the two objects. */
+ for ( ; line[i] && line[i] != ':' && line[i] != ' ' && line[i] != '\t'; i++)
;
- if (line[i] != ':')
-{
- builtin_error (_("%s: missing colon separator"), line);
- FREE (kseq);
- return -1;
-}
- i = isolate_sequence (line, i + 1, 0, );
+ translate = (line[i] != ':');
+
+ i = isolate_sequence (line, i + 1, translate, );
if (i < 0)
{
FREE (kseq);
@@ -4737,7 +4734,10 @@ bind_keyseq_to_unix_command (char *line)
/* Save the command to execute and the key sequence in the CMD_XMAP */
cmd_xmap = get_cmd_xmap_from_keymap (kmap);
- rl_generic_bind (ISMACR, kseq, value, cmd_xmap);
+ if (translate)
+rl_macro_bind (kseq, value, cmd_xmap);
+ else
+rl_generic_bind (ISMACR, kseq, value, cmd_xmap);
/* and bind the key sequence in the current keymap to a function that
understands how to execute from CMD_XMAP */
diff --git a/lib/readline/bind.c b/lib/readline/bind.c
index dc30dd84..9d4817a3 100644
--- a/lib/readline/bind.c
+++ b/lib/readline/bind.c
@@ -2861,18 +2861,12 @@ _rl_macro_dumper_internal (int print_readably,
Keymap map, char *prefix)
{
case ISMACR:
keyname = _rl_get_keyname (key);
- if (print_readably < 0)
- out = savestring ((char *)map[key].function);
- else
- out = _rl_untranslate_macro_value ((char *)map[key].function, 0);
+ out = _rl_untranslate_macro_value ((char *)map[key].function, 0);
- if (print_readably < 0)
- fprintf (rl_outstream, "\"%s%s\": %s\n", prefix ? prefix : "",
-keyname,
-out ? out : "");
- else if (print_readably > 0)
- fprintf (rl_outstream, "\"%s%s\": \"%s\"\n", prefix ? prefix : "",
+ if (print_readably)
+ fprintf (rl_outstream, "\"%s%s\"%s \"%s\"\n", prefix ? prefix : "",
keyname,
+print_readably > 0 ?
":" : "",
out ? out : "");
else
fprintf (rl_outstream, "%s%s outputs %s\n", prefix ? prefix : "",
Re: [PATCH] fix bind -X quoting
On 7/24/23 1:13 PM, Chet Ramey wrote: You could do it if you allowed, say bind -x '"\eX": \"command with spaces\" \"x\"' and then stripped the backslashes before calling rl_generic_bind, but that's not exactly backwards compatible either. Thinking about it some more, you can do it like this: bind -x $'"\\eX": \'"command with spaces" "x"\'' since bind -x allows single-quoted strings as the command to execute, and $'...' allows backslash-escaped single quotes. If we ran the command string through rl_translate_keyseq, it would allow backslash-escaped double quotes and strip the backslashes, but you get the rest of the backslash processing that you probably don't want. It's just not transitive. -- ``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: [PATCH] fix bind -X quoting
On Mon, Jul 24, 2023, 7:13 PM Chet Ramey wrote: > On 7/19/23 12:47 PM, Grisha Levit wrote: > > On Wed, Jul 19, 2023 at 10:47 AM Chet Ramey wrote: > >> Thanks for the report. It seems like your patch is incomplete, though. > >> After applying it: > >> > >> $ bind -x '"\eX": echo "x"' > >> $ bind -X > >> "\eX": "echo "x"" > >> > >> We probably need to suppress printing the double quotes around `out' if > >> print_readably < 0. > > > > Oh good point. I guess we'd need to also print a backslash if the > > first character of the command is a quote. > > Quoted command lines are tricky. Like a regular readline key binding, a > command name that starts with a double quote is assumed to be a single > double-quoted string (like any other macro), where the double quotes get > stripped before calling rl_generic_bind. Practically, this means that you > can -- and have historically been able to -- run > > bind -x '"\eX": "echo x y z"' > > and have `echo x y z' executed when you type M-X. > > Not only does this not permit quoted command names with arguments, you have > to detect the difference between a quoted string and a quoted command name > after all that information has been lost. Changing this means backwards- > incompatible changes to bind_keyseq_to_unix_command. > > You could do it if you allowed, say > > bind -x '"\eX": \"command with spaces\" \"x\"' > in my shell awk coding story , thers the quotes to get escquoted escape_deep_level deep i d wanna see such a helper function opt1 quote types opt2 if to surround string arg/s with quoted , and mainopt3 escape " ( in this case ) defaultly 1 deep but variable .. the higher the deep level number is , the more backslashes and whatever valid will appear .. basic code gen function and then stripped the backslashes before calling rl_generic_bind, but > that's not exactly backwards compatible either. > > And since the bash code parses the command like you passed it to `eval', > you can't have readline quoting double-quotes in the command string with > backslashes. > > -- > ``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: [PATCH] fix bind -X quoting
On 7/19/23 12:47 PM, Grisha Levit wrote: On Wed, Jul 19, 2023 at 10:47 AM Chet Ramey wrote: Thanks for the report. It seems like your patch is incomplete, though. After applying it: $ bind -x '"\eX": echo "x"' $ bind -X "\eX": "echo "x"" We probably need to suppress printing the double quotes around `out' if print_readably < 0. Oh good point. I guess we'd need to also print a backslash if the first character of the command is a quote. Quoted command lines are tricky. Like a regular readline key binding, a command name that starts with a double quote is assumed to be a single double-quoted string (like any other macro), where the double quotes get stripped before calling rl_generic_bind. Practically, this means that you can -- and have historically been able to -- run bind -x '"\eX": "echo x y z"' and have `echo x y z' executed when you type M-X. Not only does this not permit quoted command names with arguments, you have to detect the difference between a quoted string and a quoted command name after all that information has been lost. Changing this means backwards- incompatible changes to bind_keyseq_to_unix_command. You could do it if you allowed, say bind -x '"\eX": \"command with spaces\" \"x\"' and then stripped the backslashes before calling rl_generic_bind, but that's not exactly backwards compatible either. And since the bash code parses the command like you passed it to `eval', you can't have readline quoting double-quotes in the command string with backslashes. -- ``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: [PATCH] fix bind -X quoting
On Wed, Jul 19, 2023 at 10:47 AM Chet Ramey wrote: > Thanks for the report. It seems like your patch is incomplete, though. > After applying it: > > $ bind -x '"\eX": echo "x"' > $ bind -X > "\eX": "echo "x"" > > We probably need to suppress printing the double quotes around `out' if > print_readably < 0. Oh good point. I guess we'd need to also print a backslash if the first character of the command is a quote.
Re: [PATCH] fix bind -X quoting
On Wed, Jul 19, 2023, 4:48 PM Chet Ramey wrote: > On 7/18/23 2:22 AM, Grisha Levit wrote: > > > This patch changes rl_macro_dumper to not untranslate the macro body > > when passed a negative print_readably argument. This is technically an > > API change, so maybe not the best fix, though I doubt it will impact any > > real usage. > > Thanks for the report. It seems like your patch is incomplete, though. > After applying it: > > $ bind -x '"\eX": echo "x"' > $ bind -X > "\eX": "echo "x"" > > We probably need to suppress printing the double quotes around `out' if > print_readably < 0. > dunno the context .. \" is another way if has more than one word to preserve greets -- > ``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: [PATCH] fix bind -X quoting
On 7/18/23 2:22 AM, Grisha Levit wrote: This patch changes rl_macro_dumper to not untranslate the macro body when passed a negative print_readably argument. This is technically an API change, so maybe not the best fix, though I doubt it will impact any real usage. Thanks for the report. It seems like your patch is incomplete, though. After applying it: $ bind -x '"\eX": echo "x"' $ bind -X "\eX": "echo "x"" We probably need to suppress printing the double quotes around `out' if print_readably < 0. -- ``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/
[PATCH] fix bind -X quoting
The output of `bind -X' is not reusable if the bound command has quotes,
backslashes, etc.
$ bind -x '"\eX": echo "x"'
$ bind -X
"\eX": "echo \"x\""
$ bind -x "$(bind -X)"
$ bind -X
"\eX": "echo \\\"x\\\""
This patch changes rl_macro_dumper to not untranslate the macro body
when passed a negative print_readably argument. This is technically an
API change, so maybe not the best fix, though I doubt it will impact any
real usage.
---
bashline.c | 2 +-
lib/readline/bind.c | 6 +-
lib/readline/doc/rltech.texi | 4 +++-
3 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/bashline.c b/bashline.c
index 2fb00e82..e2b329f9 100644
--- a/bashline.c
+++ b/bashline.c
@@ -4583,7 +4583,7 @@ print_unix_command_map (void)
save = rl_get_keymap ();
cmd_xmap = get_cmd_xmap_from_keymap (save);
rl_set_keymap (cmd_xmap);
- rl_macro_dumper (1);
+ rl_macro_dumper (-1);
rl_set_keymap (save);
return 0;
}
diff --git a/lib/readline/bind.c b/lib/readline/bind.c
index ee6d6e17..bae0e6cc 100644
--- a/lib/readline/bind.c
+++ b/lib/readline/bind.c
@@ -2861,7 +2861,11 @@ _rl_macro_dumper_internal (int print_readably,
Keymap map, char *prefix)
{
case ISMACR:
keyname = _rl_get_keyname (key);
- out = _rl_untranslate_macro_value ((char *)map[key].function, 0);
+
+ if (print_readably < 0)
+ out = savestring ((char *)map[key].function);
+ else
+ out = _rl_untranslate_macro_value ((char *)map[key].function, 0);
if (print_readably)
fprintf (rl_outstream, "\"%s%s\": \"%s\"\n", prefix ? prefix : "",
diff --git a/lib/readline/doc/rltech.texi b/lib/readline/doc/rltech.texi
index 4d3f3cca..83a34a5f 100644
--- a/lib/readline/doc/rltech.texi
+++ b/lib/readline/doc/rltech.texi
@@ -1354,8 +1354,10 @@ use @code{rl_generic_bind()} instead.
@deftypefun void rl_macro_dumper (int readable)
Print the key sequences bound to macros and their values, using
the current keymap, to @code{rl_outstream}.
-If @var{readable} is non-zero, the list is formatted in such a way
+If @var{readable} is greater than zero, the list is formatted in such a way
that it can be made part of an @code{inputrc} file and re-read.
+If @var{readable} is less than zero, the macros are printed in "translated"
+form.
@end deftypefun
@deftypefun int rl_variable_bind (const char *variable, const char *value)
--
2.41.0
Re: [PATCH] unwind protect for bind -x commands
On 6/27/23 6:47 PM, Grisha Levit wrote: If SIGINT is received during the execution of a bind -x command, the memory allocated for the saved parser state is leaked and the READLINE_* variables remain in the environment Thanks for the report and fix. 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/
[PATCH] unwind protect for bind -x commands
If SIGINT is received during the execution of a bind -x command, the
memory allocated for the saved parser state is leaked and the READLINE_*
variables remain in the environment
* pcomplete.c,bashline.c:
- uw_restore_parser_state,uw_rl_set_signals: move from pcomplete.c to
bashline.c
* bashline.h:
- extern declarations for uw_restore_parser_state, uw_rl_set_signals
* bashline.c:
- unbind_bindx_vars,uw_unbind_bindx_vars: new function to unbind shell
variables set by bind -x commands
- bash_execute_unix_command: use unbind_bindx_vars, add unwind-protects
for rl_set_signals, restore_parser_state, unbind_bindx_vars
The existing use of uw_restore_parser_state in gen_shell_function_matches
creates a 'restrict' copy of the pointer to the saved parser state.
I don't really understand why that is, so I didn't do that in
bash_execute_unix_command, but wanted to note here just in case.
---
bashline.c | 40 ++--
bashline.h | 3 +++
pcomplete.c | 12
3 files changed, 37 insertions(+), 18 deletions(-)
diff --git a/bashline.c b/bashline.c
index 02f36e3a..70d6778f 100644
--- a/bashline.c
+++ b/bashline.c
@@ -4428,6 +4428,34 @@ readline_set_char_offset (int ind, int *varp)
}
}
+void
+uw_restore_parser_state (void *ps)
+{
+ restore_parser_state (ps);
+}
+
+void
+uw_rl_set_signals (void *ignore)
+{
+ rl_set_signals ();
+}
+
+static void
+unbind_bindx_vars (void)
+{
+ check_unbind_variable ("READLINE_LINE");
+ check_unbind_variable ("READLINE_POINT");
+ check_unbind_variable ("READLINE_MARK");
+ check_unbind_variable ("READLINE_ARGUMENT");
+ array_needs_making = 1;
+}
+
+static void
+uw_unbind_bindx_vars (void *ignore)
+{
+ unbind_bindx_vars ();
+}
+
int
bash_execute_unix_command (int count, int key)
{
@@ -4507,11 +4535,16 @@ bash_execute_unix_command (int count, int key)
}
array_needs_making = 1;
+ begin_unwind_frame ("bindx");
save_parser_state ();
+ add_unwind_protect (uw_unbind_bindx_vars, NULL);
+ add_unwind_protect (uw_restore_parser_state, );
+ add_unwind_protect (uw_rl_set_signals, NULL);
rl_clear_signals ();
r = parse_and_execute (savestring (cmd),
"bash_execute_unix_command", SEVAL_NOHIST);
rl_set_signals ();
restore_parser_state ();
+ discard_unwind_frame ("bindx");
v = find_variable ("READLINE_LINE");
maybe_make_readline_line (v ? value_cell (v) : 0);
@@ -4524,12 +4557,7 @@ bash_execute_unix_command (int count, int key)
if (v && legal_number (value_cell (v), ))
readline_set_char_offset (mi, _mark);
- check_unbind_variable ("READLINE_LINE");
- check_unbind_variable ("READLINE_POINT");
- check_unbind_variable ("READLINE_MARK");
- check_unbind_variable ("READLINE_ARGUMENT");
- array_needs_making = 1;
-
+ unbind_bindx_vars ();
/* and restore the readline buffer and display after command execution. */
/* If we clear the last line of the prompt above, redraw only that last
line. If the command returns 124, we redraw unconditionally as in
diff --git a/bashline.h b/bashline.h
index d9fb7379..2079799a 100644
--- a/bashline.h
+++ b/bashline.h
@@ -56,6 +56,9 @@ extern char **bash_default_completion (const char *,
int, int, int, int);
extern void set_directory_hook (void);
/* Used by programmable completion code. */
+extern void uw_rl_set_signals (void *);
+extern void uw_restore_parser_state (void *);
+
extern char *command_word_completion_function (const char *, int);
extern char *bash_groupname_completion_function (const char *, int);
extern char *bash_servicename_completion_function (const char *, int);
diff --git a/pcomplete.c b/pcomplete.c
index 410a7b7d..717a1479 100644
--- a/pcomplete.c
+++ b/pcomplete.c
@@ -1030,18 +1030,6 @@ build_arg_list (const char *cmd, const char
*cname, const char *text, WORD_LIST
return ret;
}
-static void
-uw_restore_parser_state (void *ps)
-{
- restore_parser_state (ps);
-}
-
-static void
-uw_rl_set_signals (void *ignore)
-{
- rl_set_signals ();
-}
-
/* Build a command string with
$0 == cs->funcname (function to execute for completion list)
$1 == command name (command being completed)
--
2.41.0
0001-unwind-protect-for-bind-x-commands.patch
Description: Binary data
Re: [PATCH] don't close stdin with var=x; exec {var}>&-
On 4/6/23 1:04 PM, Grisha Levit wrote:
If $var is non-empty and not a valid a number, {var}>&- silently closes fd
0.
Thanks for the report. The check should be == 0.
--
``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/
[PATCH] don't close stdin with var=x; exec {var}>&-
If $var is non-empty and not a valid a number, {var}>&- silently closes fd
0.
var=x; (exec {var}>&-; test -e /dev/fd/0); echo $?
1
Seems like the test of the return value of legal_number is incorrect.
---
redir.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/redir.c b/redir.c
index 804d9b82..267a9fc8 100644
--- a/redir.c
+++ b/redir.c
@@ -1459,7 +1459,7 @@ redir_varvalue (REDIRECT *redir)
if (val == 0 || *val == 0)
return -1;
- if (legal_number (val, ) < 0)
+ if (legal_number (val, ) <= 0)
return -1;
i = vmax; /* integer truncation */
--
2.40.0
Re: bash 5.2 bad substitution for ${x:+${x}[}
On 10/20/22 5:03 AM, Martin von Gagern wrote:
Bash Version: 5.2
Patch Level: !PATCHLEVEL!
Release Status: release
Description:
Some substitutions that used to work pre 5.2 are failing starting in
5.2. I did a git bisect on that, it's the initial 5.2 commit which
broke this,
https://git.savannah.gnu.org/cgit/bash.git/commit/?h=bash-5.2=74091dd4e8086db518b30df7f222691524469998.
According to my reproducing example below, this appears to be due to a
combination of conditional substitution, a variable enclosed in curly
braces and an unbalanced opening square bracket that I think should
only be considered as text without any semantic relevance in this
position.
Thanks for the report. This came up a couple weeks ago in
https://lists.gnu.org/archive/html/bug-bash/2022-10/msg00022.html
and is fixed in the devel branch. I've attached the patch that fixes it.
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/
*** ../bash-5.2-patched/subst.c 2022-10-05 10:22:02.0 -0400
--- subst.c 2022-10-06 15:19:08.0 -0400
***
*** 1799,1802
--- 1804,1810
}
+ #define PARAMEXPNEST_MAX 32 // for now
+ static int dbstate[PARAMEXPNEST_MAX];
+
/* Extract a parameter expansion expression within ${ and } from STRING.
Obey the Posix.2 rules for finding the ending `}': count braces while
***
*** 1829,1832
--- 1837,1842
return (extract_heredoc_dolbrace_string (string, sindex, quoted, flags));
+ dbstate[0] = dolbrace_state;
+
pass_character = 0;
nesting_level = 1;
***
*** 1853,1856
--- 1863,1868
if (string[i] == '$' && string[i+1] == LBRACE)
{
+ if (nesting_level < PARAMEXPNEST_MAX)
+ dbstate[nesting_level] = dolbrace_state;
nesting_level++;
i += 2;
***
*** 1865,1868
--- 1877,1881
if (nesting_level == 0)
break;
+ dolbrace_state = (nesting_level < PARAMEXPNEST_MAX) ?
dbstate[nesting_level] : dbstate[0];/* Guess using initial state */
i++;
continue;
bash 5.2 bad substitution for ${x:+${x}[}
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -g -O2
uname output: Linux … 5.18.16-…-amd64 #1 SMP PREEMPT_DYNAMIC Debian
5.18.16-… (2022-…) x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu
Bash Version: 5.2
Patch Level: !PATCHLEVEL!
Release Status: release
Description:
Some substitutions that used to work pre 5.2 are failing starting in
5.2. I did a git bisect on that, it's the initial 5.2 commit which
broke this,
https://git.savannah.gnu.org/cgit/bash.git/commit/?h=bash-5.2=74091dd4e8086db518b30df7f222691524469998.
According to my reproducing example below, this appears to be due to a
combination of conditional substitution, a variable enclosed in curly
braces and an unbalanced opening square bracket that I think should
only be considered as text without any semantic relevance in this
position.
Repeat-By:
bash -c 'x=""; echo "a${x:+${x}[}b"'
Work-around:
Omit the inner curly braces, i.e. use "a${x:+$x[}b".
Re: [PATCH] 4.3..devel: Fix printf %d "'X" affected by intermediate mbstate_t
On 9/24/22 9:15 PM, Koichi Murase wrote: Bash Version: 4.4 Patch Level: 12 Release Status: release Description: With a multi-byte encoding that has a non-trivial intermediate state (mbstate_t), « printf %d "'" » can be affected by the internal mbstate_t of `mbtowc'/`mblen' to produce a wrong result. Also, it can leave the internal mbstate_t in an intermediate state. Thanks for the detailed report and fix. It will be in the next devel branch push. 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/
[PATCH] 4.3..devel: Fix printf %d "'X" affected by intermediate mbstate_t
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: cygwin
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash.exe' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='cygwin' -DCONF_MACHTYPE='x86_64-unknown-cygwin'
-DCONF_VENDOR='unknown' -DLOCALEDIR='/usr/share/locale'
-DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -DRECYCLES_PIDS -I.
-I/usr/src/bash-4.4.12-3.x86_64/src/bash-4.4
-I/usr/src/bash-4.4.12-3.x86_64/src/bash-4.4/include
-I/usr/src/bash-4.4.12-3.x86_64/src/bash-4.4/lib -DWORDEXP_OPTION
-ggdb -O2 -pipe -Wimplicit-function-declaration
-fdebug-prefix-map=/usr/src/bash-4.4.12-3.x86_64/build=/usr/src/debug/bash-4.4.12-3
-fdebug-prefix-map=/usr/src/bash-4.4.12-3.x86_64/src/bash-4.4=/usr/src/debug/bash-4.4.12-3
-Wno-parentheses -Wno-format-security
uname output: CYGWIN_NT-10.0 letsnote2019 3.3.3(0.341/5/3) 2021-12-03
16:35 x86_64 Cygwin
Machine Type: x86_64-unknown-cygwin
Bash Version: 4.4
Patch Level: 12
Release Status: release
Description:
With a multi-byte encoding that has a non-trivial intermediate state
(mbstate_t), « printf %d "'" » can be affected by the internal
mbstate_t of `mbtowc'/`mblen' to produce a wrong result. Also, it
can leave the internal mbstate_t in an intermediate state.
This is because `mbtowc', which uses the internal mbstate_t, is used
by the printf builtin to get the character code of . Instead,
`mbrtowc' that receives `mbstate_t *' as an argument can be used
with a properly initialized mbstate_t. In the codebase, there are
several other similar codes relying on an undefined state of the
internal mbstate_t.
Repeat-By:
I faced a problem when I tried to get character codes of U+1
[i.e., Unicode characters outside Basic Multilingual Plane (BMP)
whose code points are larger than U+] in a UTF-8 locale in
Cygwin and MSYS2, in which sizeof(wchar_t) == 2. For example,
consider the following command:
$ printf '<%x>' $'"\U1F6D1'{1..4};echo
We expect four identical hex numbers as the result because the
character after the double quote is always for all the
four arguments. However, the actual result becomes
[bash-4.4/cygwin]$ printf '<%x>' $'"\U1F6D1'{1..4};echo
<0><0>
[bash-5.1/msys2]$ printf '<%x>' $'"\U1F6D1'{1..4};echo
The above behaviors are caused in the following way: In systems
where sizeof (wchar_t) == 2, such as Cygwin and MSYS2, the character
codes of U+1 do not fit in one wchar_t, so `mbtowc'/`mbrtowc`
wants to produce a surrogate pair consisting of two wchar_t.
1. For the first call of `mbtowc', a high surrogate (U+D800..DBFF)
is generated, and the remaining information needed to produce a
low surrogate (U+DC00..DFFF) is stored in mbstate_t.
2. The printf builtin tries to extract the code of the second
argument using `mbtowc' without clearing the internal mbstate_t.
This causes a decode error and results in <0> (or a fallback
interpretation of a remaining byte, , in bash 5.0+).
I expect the result in Cygwin/MSYS2.
Fix:
I attach a patch, r0036-avoid-internal-mbstate.patch.txt, which
includes the following changes:
* asciicode (builtins/printf.def): Even though `mbstate_t state' was
declared by `DECLARE_MBSTATE', it was not used in the original
code. We can use `mbrtowc' instead of `mbtowc', where we can pass
`state' to the fourth argument of `mbrtowc'.
There are also other similar cases relying on an uncontrolled
intermediate internal mbstate_t and affecting the internal
mbstate_t:
* mbscasecmp (lib/sh/mbscasecmp.c), mbscmp (lib/sh/mbscmp.c): In
these functions, two intermediate states for two independent
strings are mixed. We can declare two distinct mbstate_t
instances and initialize and use them.
* indirection_level_string (print_cmd.c), setifs (subst.c): These
functions also depended on an undefined internal mbstate_t. We
can declare and initialize mbstate_t `state' by `DECLARE_MBSTATE'
and use it.
* string_extract_verbatim (subst.c): `MBRLEN' and `mbrtowc' should
be called using the current mbstate_t stored in `state'. Not to
affect `state' used by `ADVANCE_CHAR', we can first copy the value
to another mbstate_t, `mbstmp', and pass it to `MBRLEN' and
`mbrtowc'.
The patch includes cleanup of a macro that becomes unused:
* include/shmbutil.h: I have removed the macro `MBLEN' in the patch
because it is not used in the codebase anymore and also because it
has the general problem and seems to be unlikely used in the
future.
--
Koichi
From 2fb725034eabf2035f1abf815345b2941922ca01 Mon Sep 17 00:00:00 2001
From: Koichi Murase
Date: Sat, 24 Sep 2022 12:55:17 +0900
Subject: [PATCH 1/2] shmbutil: avoid intermediate mbstate
---
builtins/printf.def | 2 +-
include/shmbutil.h | 2 --
lib/sh/mbscasecmp.c | 7 +++
lib/sh/mbscmp.c | 7 +++
print_cmd.c | 3 ++-
sub
Re: How come math/arithmetic cannot work by set -x
On 8/12/22 8:22 PM, Dennis Williamson wrote:
set -x; unset a; b=2; c=7; ((a = b + c)); echo "$a $b $c"; set +x
+ unset a
+ b=2
+ c=7
+ (( a = b + c ))
+ echo '9 2 7'
9 2 7
+ set +x
without the dollar signs doesn't.
"Within an expression, shell
variables may also be referenced by name without using the parameter
expansion syntax. A shell variable that is null or unset evaluates to
0 when referenced by name without using the parameter expansion syntax.
The value of a variable is evaluated as an arithmetic expression when
it is referenced"
So this is the behavior of arithmetic expansion (and, as a consequence, the
execution of the `((' command) and `set -x' will not show it. `set -x'
displays the command and its arguments before it is executed.
--
``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: How come math/arithmetic cannot work by set -x
On 8/12/22 7:27 PM, Budi wrote: How come math/arithmetic ((i=k+l)) cannot make use of set -x If you're talking about what I think you are, because that's not how `set -x' works. It's the same reason that k=2+3 echo $(( $k*5 )) echo $(( k*5 )) produces two different numbers. -- ``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: How come math/arithmetic cannot work by set -x
On Sat, Aug 13, 2022 at 06:51:04AM +0700, Budi wrote: > It doesn't work means no use on set -x, no value is shown set -x shows the command being executed, with arguments expanded. unicorn:~$ cat foo #!/bin/bash set -x a=5 b=7 c=$((a * b)) echo "$c" unicorn:~$ ./foo + a=5 + b=7 + c=35 + echo 35 35 In this case, $((a * b)) was expanded to 35 before executing the variable assignment, so that's what set -x shows. Similarly, "$c" was expanded to 35, so set -x shows that as well. What *exactly* were you expecting? We're all being forced to guess, and it's obnoxious.
Re: How come math/arithmetic cannot work by set -x
On Fri, Aug 12, 2022, at 7:40 PM, Dennis Williamson wrote:
> It works for me. What are you expecting?
>
> It would help if you show what you're doing, the result you're getting and
> what you expect instead.
I'm guessing that instead of, for example
% bash -xc 'a="(x=1)" b="2*3"; ((a+b))'
+ a='(x=1)'
+ b='2*3'
+ (( a+b ))
they want something like
% bash -xc 'a="(x=1)" b="2*3"; ((a+b))'
+ a='(x=1)'
+ b='2*3'
+ (( a+b ))
+ (( (x=1)+2*3 ))
+ (( 1+6 ))
+ (( 7 ))
or whatever. Who knows.
--
vq
Re: How come math/arithmetic cannot work by set -x
On Fri, Aug 12, 2022 at 6:51 PM Budi wrote: > It doesn't work means no use on set -x, no value is shown > > On 8/13/22, Dennis Williamson wrote: > > On Fri, Aug 12, 2022, 6:28 PM Budi wrote: > > > >> How come math/arithmetic ((i=k+l)) cannot make use of set -x > >> > >> Please help.. > >> (so annoying). > >> > > > > > > It works for me. What are you expecting? > > > > It would help if you show what you're doing, the result you're getting > and > > what you expect instead. > > > > "It doesn't work" conveys no information whatsoever. > > > >> > > > Hmmm... interesting. $ set -x; unset a; b=2; c=7; ((a = $b + $c)); echo "$a $b $c"; set +x + unset a + b=2 + c=7 + (( a = 2 + 7 )) + echo '9 2 7' 9 2 7 + set +x shows the values in the arithmetic expression, but set -x; unset a; b=2; c=7; ((a = b + c)); echo "$a $b $c"; set +x + unset a + b=2 + c=7 + (( a = b + c )) + echo '9 2 7' 9 2 7 + set +x without the dollar signs doesn't. Also, note that this message includes a thorough example of doing, result, expecting. -- Visit serverfault.com to get your system administration questions answered.
Re: How come math/arithmetic cannot work by set -x
It doesn't work means no use on set -x, no value is shown On 8/13/22, Dennis Williamson wrote: > On Fri, Aug 12, 2022, 6:28 PM Budi wrote: > >> How come math/arithmetic ((i=k+l)) cannot make use of set -x >> >> Please help.. >> (so annoying). >> > > > It works for me. What are you expecting? > > It would help if you show what you're doing, the result you're getting and > what you expect instead. > > "It doesn't work" conveys no information whatsoever. > >> >
Re: How come math/arithmetic cannot work by set -x
On Fri, Aug 12, 2022, 6:28 PM Budi wrote: > How come math/arithmetic ((i=k+l)) cannot make use of set -x > > Please help.. > (so annoying). > It works for me. What are you expecting? It would help if you show what you're doing, the result you're getting and what you expect instead. "It doesn't work" conveys no information whatsoever. >
How come math/arithmetic cannot work by set -x
How come math/arithmetic ((i=k+l)) cannot make use of set -x Please help.. (so annoying).
Signed integer overflow in ansicstr() when parsing \x{...}
Machine: aarch64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -g -Og -fsanitize=undefined
uname output: Linux ubuntu 5.15.0-1013-oracle #17~20.04.1-Ubuntu SMP Mon Jul 4
05:29:46 UTC 2022 aarch64 aarch64 aarch64 GNU/Linux
Machine Type: aarch64-unknown-linux-gnu
Bash Version: 5.1
Patch Level: 16
Release Status: release
Description:
Parsing very long \x{...} sequences inside $''-strings triggers
signed integer overflow, which is undefined behavior.
Repeat-By:
$ ./configure CFLAGS='-g -Og -fsanitize=undefined'
...
$ make
...
$ ./bash -n <<< "\$'\\x{}'"
strtrans.c:149:14: runtime error: signed integer overflow: 268435455 * 16
cannot be represented in type 'int'
Fix:
Use an unsigned variable for arithmetic, like when parsing \u.
--
Jakub Wilk
Re: Inconsistency between fc and C-x C-e
On Fri, Jun 10, 2022, at 10:19 AM, Chet Ramey wrote:
> I didn't look at more than mailx, but the description there makes it clear
> that $EDITOR needs to expand to a command name. `more' has similar wording
> ("The name of the editor shall be taken from the environment variable
> EDITOR.") and talks about what to do if the last pathname component in
> $EDITOR is `vi' or `ex'.
That's certainly the common-sense interpretation -- and no doubt
the intended one, given the historical behavior you mentioned.
I was reading phrases like "Determine the name of a utility" and
"The name of the editor shall be taken from the environment variable"
as allowing some wiggle room for the variable contents, but I was
probably overthinking it.
--
vq
Re: Inconsistency between fc and C-x C-e
On 6/9/22 11:57 PM, Lawrence Velázquez wrote:
On Thu, Jun 9, 2022, at 8:37 PM, Luciano wrote:
By the way, git seems to interpret the EDITOR variable in a way
consistent with C-x C-e, while the pass program as I said seems to just
execute $EDITOR, like fc. I wonder if POSIX leaves room for
interpretation here.
It does, insofar as it barely concerns itself with EDITOR at all.
It only specifies that the "crontab", "fc", "mailx", and "more"
utilities use EDITOR and advises other applications to avoid using
it in a conflicting manner. (The descriptions of the aforementioned
utilities are not all that detailed vis-à-vis EDITOR and could
reasonably be interpreted as allowing either method, but it doesn't
really matter as far as other utilities are concerned.)
I didn't look at more than mailx, but the description there makes it clear
that $EDITOR needs to expand to a command name. `more' has similar wording
("The name of the editor shall be taken from the environment variable
EDITOR.") and talks about what to do if the last pathname component in
$EDITOR is `vi' or `ex'.
As I said in a different message, historical convention is that these are
command names.
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/
Re: Inconsistency between fc and C-x C-e
On 6/9/22 8:37 PM, Luciano wrote:
On Wed, Jun 08, 2022 at 05:49:52PM -0400, Greg Wooledge wrote:
You could create a wrapper script, put it in your $HOME/bin/ directory
(and make sure that's in PATH), and then set EDITOR to that wrapper.
That should be much more reliable, especially if other programs also
use $EDITOR (which they might).
Yes, I think that's the most reasonable thing to do, and I'm going to do
that.
It's consistent with what POSIX specifies.
On Thu, Jun 09, 2022 at 11:40:26AM -0400, Chet Ramey wrote:
The edit-and-execute-command key binding runs
fc -e "${VISUAL:-${EDITOR:-emacs}}"
[...] while the fc command without options runs (internally)
"${FCEDIT:-${EDITOR:-vi}}"
Well that explains it! is there a reason why fc -e is used here for C-x C-e
instead of just plain "${VISUAL:-${EDITOR:-emacs}}" ?
I'm not sure I understand the question. You need to invoke fc to get the
right behavior: get a line from the history list, edit it, and execute the
result. It's a waste to duplicate code to do the same thing.
The default editor string is different because `fc' is supposed to default
to $FCEDIT and it would be unexpected for the C-xC-e key binding to use
that if it's defined.
By the way, git seems to interpret the EDITOR variable in a way
consistent with C-x C-e, while the pass program as I said seems to just
execute $EDITOR, like fc. I wonder if POSIX leaves room for interpretation here.
POSIX says little about the value of EDITOR, but makes it an application
requirement (the same thing as a user requirement) for the argument to
`fc -e' to be "a utility name, subject to search via the PATH variable."
Since $FCEDIT is the default editor, the same requirement holds for it
after expansion.
It's historical convention that VISUAL and EDITOR are subject to the same
restriction, but they are not described separately in the POSIX Environment
Variables section. (And yes, historically they were different and had
different requirements.)
The POSIX utilities that use $EDITOR don't say much, either, but the mailx
description makes it clear that EDITOR needs to expand to a command name
("the name of a utility to invoke").
Anyway, any sane person would probably just follow Greg's advice.
It provides maximum flexibility.
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/
Re: Inconsistency between fc and C-x C-e
On Thu, Jun 9, 2022, at 8:37 PM, Luciano wrote: > By the way, git seems to interpret the EDITOR variable in a way > consistent with C-x C-e, while the pass program as I said seems to just > execute $EDITOR, like fc. I wonder if POSIX leaves room for > interpretation here. It does, insofar as it barely concerns itself with EDITOR at all. It only specifies that the "crontab", "fc", "mailx", and "more" utilities use EDITOR and advises other applications to avoid using it in a conflicting manner. (The descriptions of the aforementioned utilities are not all that detailed vis-à-vis EDITOR and could reasonably be interpreted as allowing either method, but it doesn't really matter as far as other utilities are concerned.) -- vq
Re: Inconsistency between fc and C-x C-e
On Wed, Jun 08, 2022 at 05:49:52PM -0400, Greg Wooledge wrote:
>You could create a wrapper script, put it in your $HOME/bin/ directory
>(and make sure that's in PATH), and then set EDITOR to that wrapper.
>That should be much more reliable, especially if other programs also
>use $EDITOR (which they might).
Yes, I think that's the most reasonable thing to do, and I'm going to do
that.
On Thu, Jun 09, 2022 at 11:40:26AM -0400, Chet Ramey wrote:
> The edit-and-execute-command key binding runs
>
> fc -e "${VISUAL:-${EDITOR:-emacs}}"
>
> [...] while the fc command without options runs (internally)
>
> "${FCEDIT:-${EDITOR:-vi}}"
Well that explains it! is there a reason why fc -e is used here for C-x C-e
instead of just plain "${VISUAL:-${EDITOR:-emacs}}" ?
By the way, git seems to interpret the EDITOR variable in a way
consistent with C-x C-e, while the pass program as I said seems to just
execute $EDITOR, like fc. I wonder if POSIX leaves room for interpretation
here.
Anyway, any sane person would probably just follow Greg's advice.
Saludos
Re: Inconsistency between fc and C-x C-e
On 6/8/22 5:06 PM, Luciano wrote:
Hi!
I had the terrible idea to set my EDITOR variable to something too
complex. I had to pass some options with whitespace to vim, so i decided
to use `eval`. I managed to get something working, but the way the
EDITOR variable is interpreted isn't consistent
to provide an example, if one sets EDITOR in .bashrc to:
EDITOR="eval vim --cmd \" set statusline=HI-FROM-\\\$EDITOR laststatus=2 \" --
"
then doing 'fc' works fine, (I get the "HI-FROM-$EDITOR" message on the
status line"), but C-x C-e seems to wipe out the ' \" ' arguments altogether,
leaving eval with only loose words after '--cmd'.
C-x C-e seems to have an extra pass with character escaping, doubling
every \ character makes C-x C-e work as intended, but now fc doesn't
work anymore!
The edit-and-execute-command key binding runs
fc -e "${VISUAL:-${EDITOR:-emacs}}"
(since it's in emacs mode) as a shell command, which means the shell parses
and executes it, while the fc command without options runs (internally)
"${FCEDIT:-${EDITOR:-vi}}"
fc builds a new command line from its options and has the shell parse and
execute it.
The first variant (C-xC-e) will therefore have the arguments expanded
before fc sees the command, and again when fc executes the command it
constructs.
The second will have $EDITOR expanded once, as part of the command fc
constructs.
--
``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: Inconsistency between fc and C-x C-e
On Wed, Jun 08, 2022 at 06:06:51PM -0300, Luciano wrote: > I had the terrible idea to set my EDITOR variable to something too > complex. I had to pass some options with whitespace to vim, so i decided > to use `eval`. [...] You could create a wrapper script, put it in your $HOME/bin/ directory (and make sure that's in PATH), and then set EDITOR to that wrapper. That should be much more reliable, especially if other programs also use $EDITOR (which they might).
Inconsistency between fc and C-x C-e
Hi! I had the terrible idea to set my EDITOR variable to something too complex. I had to pass some options with whitespace to vim, so i decided to use `eval`. I managed to get something working, but the way the EDITOR variable is interpreted isn't consistent to provide an example, if one sets EDITOR in .bashrc to: EDITOR="eval vim --cmd \" set statusline=HI-FROM-\\\$EDITOR laststatus=2 \" -- " then doing 'fc' works fine, (I get the "HI-FROM-$EDITOR" message on the status line"), but C-x C-e seems to wipe out the ' \" ' arguments altogether, leaving eval with only loose words after '--cmd'. C-x C-e seems to have an extra pass with character escaping, doubling every \ character makes C-x C-e work as intended, but now fc doesn't work anymore! By the way, fc seems to be the one that works as intended, because programs such as pass interpret the $EDITOR variable the same way as fc does. This is clearly not a very important bug, I know! Greetings. Luciano
Re: declare -x non-exportable variable types
On Fri, Feb 25, 2022 at 8:52 PM Chet Ramey wrote: > On 2/25/22 12:55 PM, Léa Gris wrote: > > Le 25/02/2022 à 16:49, Chet Ramey écrivait : > > > >> You can't export array variables, period. You can't export attributes, > >> only variable names and values. You still can't export attributes. > There > >> is no way to export attributes > > > > Chet, I heard you, I understood it and I knew it before, while I was > > writing my message, and still now. > > > > It feels like that you were either in a bad mood or that I didn't manage > to > > express my remarks and thoughts as clearly as I would have liked. > > OK. I don't think my response was especially tense (now, terse, maybe). I > simply disagree with much of your premise. > > > Now that you and I are, were and still are (I reassure you) in absolute > > agreement with: "Bash variable attributes and, or arrays are > incompatible > > with environment variables" (undisputed fact)... > > Variables have names, values, and attributes. Environment variables don't > have enough information to contain all three (or two, in the case of > arrays, without some special encoding). > you map those as extension in free space, just like you do with your function to children passment my only comment to this > > > > Is it possible that: if these variables are passed explicitly as > > environment variables with -x or export : > > > > - Either Bash returns an error because of "variable flags are > incompatible > > with the environment, and it's a mistake to export Bash variables with > > flags", rather than having different behaviours (pass value, nothing, > > name...) based on the original Bash variable flags/type? > > But you have not shown such `different behaviors'. In the case of array > variables, not exporting them is a conscious choice based on the issues > encoding the values, and that is documented. Is that what you mean? > > > > > - Or that Bash should now be able to "convert" the value as it does now, > > but in a more consistent way? > > I simply don't see the inconsistency you claim is there. Bash exports names > and values for variables to which you assign the export attribute. > > > - Or that the documentation contains an explicit description of what > > happens when one tries to export a Bash variable with flags/types (even > > just documented as: "The result of exporting Bash variables with > attributes > > is indeterminate"), which might be an appropriate clarification? > > OK, what's indeterminate about it? I showed how the behavior from your > first message was all consistent. > > -- > ``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: declare -x non-exportable variable types
On 2/25/22 12:55 PM, Léa Gris wrote: Le 25/02/2022 à 16:49, Chet Ramey écrivait : You can't export array variables, period. You can't export attributes, only variable names and values. You still can't export attributes. There is no way to export attributes Chet, I heard you, I understood it and I knew it before, while I was writing my message, and still now. It feels like that you were either in a bad mood or that I didn't manage to express my remarks and thoughts as clearly as I would have liked. OK. I don't think my response was especially tense (now, terse, maybe). I simply disagree with much of your premise. Now that you and I are, were and still are (I reassure you) in absolute agreement with: "Bash variable attributes and, or arrays are incompatible with environment variables" (undisputed fact)... Variables have names, values, and attributes. Environment variables don't have enough information to contain all three (or two, in the case of arrays, without some special encoding). Is it possible that: if these variables are passed explicitly as environment variables with -x or export : - Either Bash returns an error because of "variable flags are incompatible with the environment, and it's a mistake to export Bash variables with flags", rather than having different behaviours (pass value, nothing, name...) based on the original Bash variable flags/type? But you have not shown such `different behaviors'. In the case of array variables, not exporting them is a conscious choice based on the issues encoding the values, and that is documented. Is that what you mean? - Or that Bash should now be able to "convert" the value as it does now, but in a more consistent way? I simply don't see the inconsistency you claim is there. Bash exports names and values for variables to which you assign the export attribute. - Or that the documentation contains an explicit description of what happens when one tries to export a Bash variable with flags/types (even just documented as: "The result of exporting Bash variables with attributes is indeterminate"), which might be an appropriate clarification? OK, what's indeterminate about it? I showed how the behavior from your first message was all consistent. -- ``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: declare -x non-exportable variable types
Le 25/02/2022 à 16:49, Chet Ramey écrivait : You can't export array variables, period. You can't export attributes, only variable names and values. You still can't export attributes. There is no way to export attributes Chet, I heard you, I understood it and I knew it before, while I was writing my message, and still now. It feels like that you were either in a bad mood or that I didn't manage to express my remarks and thoughts as clearly as I would have liked. I'm sorry for what happened and I didn't expect to receive such a tense reaction. Now that you and I are, were and still are (I reassure you) in absolute agreement with: "Bash variable attributes and, or arrays are incompatible with environment variables" (undisputed fact)... Is it possible that: if these variables are passed explicitly as environment variables with -x or export : - Either Bash returns an error because of "variable flags are incompatible with the environment, and it's a mistake to export Bash variables with flags", rather than having different behaviours (pass value, nothing, name...) based on the original Bash variable flags/type? - Or that Bash should now be able to "convert" the value as it does now, but in a more consistent way? - Or that the documentation contains an explicit description of what happens when one tries to export a Bash variable with flags/types (even just documented as: "The result of exporting Bash variables with attributes is indeterminate"), which might be an appropriate clarification? -- Léa Gris
Re: declare -x non-exportable variable types
On 2/22/22 1:35 PM, Léa Gris wrote: declare -x variable with unexportable flag/type is handled quite inconsistently: $ unset int_value && declare -ix int_value=42 && bash -c 'declare -p int_value' declare -x int_value="42" You can't export attributes, since the only vehicle to export objects to child processes is environment variables. In this case, the variable was found in the environment at shell startup, so it was given the export attribute in the child shell. That is standard behavior, defined by POSIX. $ unset array && declare -ax array=(foo bar) && bash -c 'declare -p array' bash: line 1: declare: array: not found $ unset assoc && declare -Ax assoc=([key1]=foo [key2]=bar) && bash -c 'declare -p assoc' bash: line 1: declare: assoc: not found You can't export array variables, period. $ unset upper && declare -ux upper='hello' && bash -c 'declare -p upper' declare -x upper="HELLO" $ unset lower && declare -lx lower='WORLD' && bash -c 'declare -p lower' declare -x lower="world" You can't export attributes, only variable names and values. $ unset str && unset -n ref && declare str=hello && declare -nx ref=str && bash -c 'declare -p ref' declare -x ref="str" You told declare to act on the nameref variable (-n) and export it (-x). You still can't export attributes. The inconsistency is that sometimes: - It exports the variable with its translated value (integer to string, upper, lower) Because these attributes result in behavior at assignment time. The converted value is what is stored and returned when the variable is referenced. The original value used in the assignment statement is discarded after being converted. - It exports nothing of array or associative array, despite that in Bash, array referenced without an index returns the first element, but not when exported. Bash doesn't export array variables. There is code to do it in there, and has been for a long time, but it's not enabled. - It export the reference name of nameref, despite it could export the value of the referee. If you want to export the referenced variable, don't tell declare to operate on the name reference instead. Something like unset str && unset -n ref && declare str=hello && declare -n ref=str && declare -x ref ./bash -c 'declare -p str ref' would easily do what you want. My stance on this is that there is no real consistent way to export variables with incompatible flags; and I wonder if to be consistent, the declaration statement could be erroring instead, when the other variable flag are incompatible with export. There is no way to export attributes, period, regardless of whether they are `incompatible with export.' This means that the export command would expand the variable value before exporting, but the declare, local and typeset statements would error if flags are incompatible with -x export. There are no flags that are compatible or incompatible with export. -- ``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/
declare -x non-exportable variable types
declare -x variable with unexportable flag/type is handled quite inconsistently: $ unset int_value && declare -ix int_value=42 && bash -c 'declare -p int_value' declare -x int_value="42" $ unset array && declare -ax array=(foo bar) && bash -c 'declare -p array' bash: line 1: declare: array: not found $ unset assoc && declare -Ax assoc=([key1]=foo [key2]=bar) && bash -c 'declare -p assoc' bash: line 1: declare: assoc: not found $ unset upper && declare -ux upper='hello' && bash -c 'declare -p upper' declare -x upper="HELLO" $ unset lower && declare -lx lower='WORLD' && bash -c 'declare -p lower' declare -x lower="world" $ unset str && unset -n ref && declare str=hello && declare -nx ref=str && bash -c 'declare -p ref' declare -x ref="str" The inconsistency is that sometimes: - It exports the variable with its translated value (integer to string, upper, lower) - It exports nothing of array or associative array, despite that in Bash, array referenced without an index returns the first element, but not when exported. - It export the reference name of nameref, despite it could export the value of the referee. My stance on this is that there is no real consistent way to export variables with incompatible flags; and I wonder if to be consistent, the declaration statement could be erroring instead, when the other variable flag are incompatible with export. For the built-in export or system export command, a consistent conversion of the value sounds an acceptable behavior: export int_value # export with string of value export array # export with value of first elmeent export assoc # export empty value (same as referencing an associative array without a [key]. export upper; export lower # export with converted value export nameref # export with value of the referee This means that the export command would expand the variable value before exporting, but the declare, local and typeset statements would error if flags are incompatible with -x export. -- Léa Gris
Re: Add {{ }}, ${{ }}, return n [x], and $:
On Sat, May 1, 2021, 10:58 Robert Elz, > | You also would almost always want to enable the > | subshell to avoid the parent from getting its parameters altered. > > Many cases, yes, the point is that not forking works in the simple > cases where it is most desired to not fork for speed $(echo ...) or > more probably $(printf ... ) but in more than just those cases, > extracting info from many shell built-in commands ( nfiles=$(ulimit -Sn) ) > can be handled without forking. > The problem is most people wouldn't want this optimization for simple commands but rather on function calls where alteration of parameters is unpredictable. > Don't misunderstand though, getting this right is not trivial, detecting > when it is safe requires a bunch of code, and handling issues like very > large > output streams (which would normally simply fill the pipe and hang a forked > process until read) take care. > > It is however possible, and when implemented, simply works in the cases > where it is possible, with all scripts, new and old. > It's very fragile to implement and the outcome of reliability is uncertain. Having a set of new commands that allow it to be done with clearness is better and avoids intrusive modifications. > The problem with new invented features is that they tend to only work in > one shell (at least initially) which means people prefer not to use them, > in order to make their scripts more portable, which means other > implementors > are under no pressure to copy the feature...Implemented optimisations > for the standard shell syntax simply work, and improve performance, while > still allowing the script to work anywhere. > I'm not really concerned about portability for this. Bash has always made its own fruitful implementations. -- konsolebox
Re: Add {{ }}, ${{ }}, return n [x], and $:
To Chet: Any thoughts on this? -- konsolebox
Re: Document -x and -vx give the same results
On 11/14/21 11:40 AM, 積丹尼 Dan Jacobson wrote: Man page says: -vPrint shell input lines as they are read. -xPrint commands and their arguments as they are executed. Perhaps mention that -x and -vx give the same results, often or always. They don't. -- ``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: Document -x and -vx give the same results
On Mon, Nov 15, 2021 at 04:04:36AM +0800, 積丹尼 Dan Jacobson wrote: > I was testing -xeu vs. -vxeu on > > set -xeu > set /var/lib/exim4/config.autogenerated > cp $@ /tmp > update-exim4.conf --verbose > diff /tmp $@||: > set update-exim4.conf.conf > echo . $PWD/$@-jidanni > /tmp/$@ > diff $@ /tmp > > and no matter STDOUT or STDERR they gave the same results, there in > emacs' *compilation* buffer. 1) What does emacs have to do with anything? Run the script from a shell. 2) Your script has no compound commands of any kind. No functions, no loops, no if statements, no case statements, no subshells, no braced command groups. Nothing at all that would indicate the difference between -v and -x. Try a script with some of the above.
Re: Document -x and -vx give the same results
I was testing -xeu vs. -vxeu on set -xeu set /var/lib/exim4/config.autogenerated cp $@ /tmp update-exim4.conf --verbose diff /tmp $@||: set update-exim4.conf.conf echo . $PWD/$@-jidanni > /tmp/$@ diff $@ /tmp and no matter STDOUT or STDERR they gave the same results, there in emacs' *compilation* buffer.
Re: Document -x and -vx give the same results
On Mon, Nov 15, 2021 at 12:40:22AM +0800, 積丹尼 Dan Jacobson wrote:
> Man page says:
>-vPrint shell input lines as they are read.
> -xPrint commands and their arguments as they are executed.
> Perhaps mention that -x and -vx give the same results, often or always.
> GNU bash, version 5.1.8
They're extremely different.
-v only prints lines when bash reads them from its script. NOT when
bash executes them. It prints the line exactly as it's read, without
any expansions.
-x prints commands that bash EXECUTES. Arguments are expanded, and
redirections are not shown.
You almost never want -v. It's pretty useless.
unicorn:~$ cat foo
#!/bin/bash
for i in {1..10}; do
: stuff
done
unicorn:~$ bash -v foo
#!/bin/bash
for i in {1..10}; do
: stuff
done
unicorn:~$ bash -x foo
+ for i in {1..10}
+ : stuff
+ for i in {1..10}
+ : stuff
+ for i in {1..10}
+ : stuff
+ for i in {1..10}
+ : stuff
+ for i in {1..10}
+ : stuff
+ for i in {1..10}
+ : stuff
+ for i in {1..10}
+ : stuff
+ for i in {1..10}
+ : stuff
+ for i in {1..10}
+ : stuff
+ for i in {1..10}
+ : stuff
In the "bash -v foo" output, you can see each line of the script as it
gets read. Bash reads the entire for loop at once, then parses it, then
runs it. The -v output shows you NOTHING after the loop has been read.
The -x output shows you each iteration of the loop.
Re: Document -x and -vx give the same results
On Sun, Nov 14, 2021, at 11:40 AM, 積丹尼 Dan Jacobson wrote: > Man page says: >-vPrint shell input lines as they are read. > -xPrint commands and their arguments as they are executed. > Perhaps mention that -x and -vx give the same results, often or always. They don't, though. % bash -xc 'echo "$BASH_VERSION"' + echo '5.1.8(1)-release' 5.1.8(1)-release % bash -xvc 'echo "$BASH_VERSION"' echo "$BASH_VERSION" + echo '5.1.8(1)-release' 5.1.8(1)-release -- vq
Document -x and -vx give the same results
Man page says: -vPrint shell input lines as they are read. -xPrint commands and their arguments as they are executed. Perhaps mention that -x and -vx give the same results, often or always. GNU bash, version 5.1.8
Re: [PATCH] devel: fix segfault by unset 'assoc[${x[0]}]'
On 10/6/21 10:47 PM, Koichi Murase wrote:
I'd like the default behavior to be closer to what it is when
assoc_expand_once is enabled, as I said back in March. I think it's
going to be better for users in the long run.
Does that mean the behavior with `assoc_expand_once' being disabled
also modified in a way incompatible with older Bash versions? I have
been thinking that `shopt -s assoc_expand_once' would be the default
in the future keeping the behavior of `shopt -u assoc_expand_once'.
My original vision was to modify behavior so that, at least for features
like arithmetic expansion and the `[[' command, it would not be needed at
all, and the behavior that users expect naturally would be the default.
Shell builtins are a different issue, since their arguments already undergo
the standard set of word expansions. I had hoped to be able to modify the
default behavior without too much incompatibility.
If the behavior of `shopt -u assoc_expand_once' would also be
modified, I would like to request another switch for the
backward-compatible behavior, in particular, a specific shopt switch
(but not a setting something like `BASH_COMPAT=51' which would involve
other behavior changes). Anyway, we need to maintain the code of the
backward-compatible behavior.
So far, I think I've kept things mostly compatible.
I see. In order to make such architectural changes, I feel we first
need to determine how the behavior should be changed. I guess such a
discussion would be again as long as the one in March. Maybe this
would become just a repetition of the discussion in March, but to
summarize,
* I still feel that the cleanest solution is to introduce a special
the syntax-level rule for `unset arr[...]' where the part `arr[...]'
is treated as if the right-hand side of a variable assignment (just
like in other assignment builtins such as `declare', `local',
`export', etc.), i.e., pathname expansions and word splitting is not
performed on the arguments of the form `name[xxx]'.
I'm not there yet with this one. I feel like the existing quoting can do
the job. The difference between this and a variable assignment is that
variable assignments already have defined behavior. This would be a new
change.
This might be also useful to distinguish the all-element unset «
unset a[@] » from the unset of the element of key='@' « unset a['@']
».
There are some changes along these lines in the devel branch already.
* I would like to request a backward-compatible mode where the extra
expansions of array subscripts are performed the same as the older
versions of Bash. I would like to see a specific option for this
mode rather than `BASH_COMPAT=51' which would involve other
behavioral changes.
It's those backward-compatible behaviors that are the problem. Expanding
the subscript multiple times, no matter what the intention was initially,
is the source of most of the issues we're trying to address.
* I feel we need to care about the consistency with the extra
expansions performed in other contexts:
- printf -v 'a[$key]'
- read 'a[$key]'
- declare 'a[$key]=1'
- vref='a[$key]'; echo "${!vref}"
- declare -n nref='a[$key]'
I'm working through these. I think there's a decent framework for them in
the devel branch right now, but I haven't made any substantial changes in
behavior.
- etc.
a better architectural solution.
This will not change the observable behavior, but if I would refactor
it, I'd make `valid_array_referecen' return the extracted subscript
and let `unbind_array_element' just receive the extracted subscript
rather than make `unbind_array_element' again extract the subscript.
Thanks, I'll look at this.
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/
Re: [PATCH] devel: fix segfault by unset 'assoc[${x[0]}]'
> I'd like the default behavior to be closer to what it is when
> assoc_expand_once is enabled, as I said back in March. I think it's
> going to be better for users in the long run.
Does that mean the behavior with `assoc_expand_once' being disabled
also modified in a way incompatible with older Bash versions? I have
been thinking that `shopt -s assoc_expand_once' would be the default
in the future keeping the behavior of `shopt -u assoc_expand_once'.
If the behavior of `shopt -u assoc_expand_once' would also be
modified, I would like to request another switch for the
backward-compatible behavior, in particular, a specific shopt switch
(but not a setting something like `BASH_COMPAT=51' which would involve
other behavior changes). Anyway, we need to maintain the code of the
backward-compatible behavior.
> Only that I'd like a more comprehensive behavioral change. Your fix
> is fine for the limited scope it tackles (resolving the discrepancy
> between valid_array_reference and unbind_array_element).
I see.
> > Yes, but I feel like this is another design issue which is irrelevant
> > for the fix of the present small problem.
>
> Sure, but that's why we're talking through the issue. Your fix is
> fine for the problem it intends to solve, now I'd like to go beyond
> it and figure out a better architectural solution.
I see. In order to make such architectural changes, I feel we first
need to determine how the behavior should be changed. I guess such a
discussion would be again as long as the one in March. Maybe this
would become just a repetition of the discussion in March, but to
summarize,
* I still feel that the cleanest solution is to introduce a special
the syntax-level rule for `unset arr[...]' where the part `arr[...]'
is treated as if the right-hand side of a variable assignment (just
like in other assignment builtins such as `declare', `local',
`export', etc.), i.e., pathname expansions and word splitting is not
performed on the arguments of the form `name[xxx]'.
This might be also useful to distinguish the all-element unset «
unset a[@] » from the unset of the element of key='@' « unset a['@']
».
But the problem might be that this may require non-trivial changes
to the existing codebase.
* I would like to request a backward-compatible mode where the extra
expansions of array subscripts are performed the same as the older
versions of Bash. I would like to see a specific option for this
mode rather than `BASH_COMPAT=51' which would involve other
behavioral changes.
* I feel we need to care about the consistency with the extra
expansions performed in other contexts:
- printf -v 'a[$key]'
- read 'a[$key]'
- declare 'a[$key]=1'
- vref='a[$key]'; echo "${!vref}"
- declare -n nref='a[$key]'
- etc.
> a better architectural solution.
This will not change the observable behavior, but if I would refactor
it, I'd make `valid_array_referecen' return the extracted subscript
and let `unbind_array_element' just receive the extracted subscript
rather than make `unbind_array_element' again extract the subscript.
I attach a patch `r0029-0002b-refactor-unset.patch' to illustrate this
strategy. This patch bases on the current devel branch. This patch
gives an alternative solution for the following patches (sorry if you
have already applied some of them):
- `0002-allow-nesting-and-quoting-in-assoc-subscripts-when-a.patch' in
https://lists.gnu.org/archive/html/bug-bash/2021-10/msg00051.html
- `0001-arrayfunc.c-unset_array_element-fix-a-bug-that-the-f.patch' in
https://lists.gnu.org/archive/html/bug-bash/2021-10/msg00059.html
--
Koichi
r0029-0002b-refactor-unset.patch
Description: Binary data
Re: [PATCH] devel: fix segfault by unset 'assoc[${x[0]}]'
On 10/5/21 10:39 PM, Koichi Murase wrote:
>> You're right, there should be no `nesting' considered at all. By the time
>> unbind_array_element is called, since it's only called from unset_builtin,
>> the word and subscript should have already undergone all the expansion
>> they're going to. There should be no need to interpret ${} or $() in the
>> subscript: since associative arrays can have arbitrary subscripts, you
>> should not attempt to parse the subscript contents.
>
> Yeah, I think the above paragraph describes the expected behavior when
> `assoc_expand_once' is turned on.
>
> But in this patch, I actually aim to fix the behavior of the
> backward-compatible mode (with `assoc_expand_once' turned off). In
> the patch, I suggested to remove `(var && assoc_p(var))' from the
> skipsubscript flag for the nesting consideration
I understand. I'd like the default behavior to be closer to what it is
when assoc_expand_once is enabled, as I said back in March. I think it's
going to be better for users in the long run.
>> It can shortcut and say "ok, if it passes valid_array_reference, we should
>> just consider the entire argument as one word as long as the final
>> character is `]'." This is again where backwards compatibility and
>> assoc_expand_once matter.
>>
>> We can apply your change, but it is still incomplete
>
> What is exactly the incompleteness that you focus on in this context?
Only that I'd like a more comprehensive behavioral change. Your fix is
fine for the limited scope it tackles (resolving the discrepancy between
valid_array_reference and unbind_array_element).
>> The real issue is that it's still going to expand the subscript for
>> backwards compatibility. I think that's going to have to be solved
>> at a higher level.
>
> Yes, but I feel like this is another design issue which is irrelevant
> for the fix of the present small problem.
Sure, but that's why we're talking through the issue. Your fix is fine
for the problem it intends to solve, now I'd like to go beyond it and
figure out a better architectural solution.
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/
Re: [PATCH] devel: fix segfault by unset 'assoc[${x[0]}]'
> The difference is that valid_array_reference can be called before
> any of the subscript is expanded, in which case you need to parse
> things that can be expanded, where unbind_array_element is called
> after all the expansions are performed (but see below).
>
> So let's see if we can talk through this.
>
> [...]
>
> You're right, there should be no `nesting' considered at all. By the time
> unbind_array_element is called, since it's only called from unset_builtin,
> the word and subscript should have already undergone all the expansion
> they're going to. There should be no need to interpret ${} or $() in the
> subscript: since associative arrays can have arbitrary subscripts, you
> should not attempt to parse the subscript contents.
Yeah, I think the above paragraph describes the expected behavior when
`assoc_expand_once' is turned on.
But in this patch, I actually aim to fix the behavior of the
backward-compatible mode (with `assoc_expand_once' turned off). In
the patch, I suggested to remove `(var && assoc_p(var))' from the
skipsubscript flag for the nesting consideration as
> -len = skipsubscript (sub, 0, (flags_NOEXPAND) || (var &&
> assoc_p(var))); /* XXX */
> +len = skipsubscript (sub, 0, flags_NOEXPAND); /* XXX */
Here, `(flags & VA_NOEXPAND)' is always `1' when `assoc_expand_once'
is turned on, so the above change does not affect the behavior of
`assoc_expand_once' mode but affect the behavior of the
backward-compatible mode.
> However, there is backwards compatibility to consider, which is why
> assoc_expand_once isn't set by default and the code attempts to run the
> subscript through word expansion.
Yeah, that's the issue.
> In this example, the quoting prevents the shell from recognizing the
> word as an array reference before the quote removal occurs and the
> word gets passed to the unset builtin, so it can't set any hints for
> unset. unset sees `a[${b[0]}]', which is ambiguous.
I thought the extra expansions are always performed in the
backward-compatible behavior and never performed in the
`assoc_expand_once' mode, so there is no ambiguity once the current
mode is given.
In the backward-compatible mode (i.e., in older Bash and in newer Bash
with `assoc_expand_once' turned off), the subscripts of « unset -v
'a[...]' » have been always subject to the extra expansions. If we
accept this extra expansions as a design, it is actually well-defined
and unambiguous, and it always works as expected if one always quotes
the arguments of `unset' (and other builtins such as `printf -v',
`read', `mapfile', etc.) as « unset -v 'a[$key]' ». Actually, this is
the only way to make it work in all the Bash versions (with
`assoc_expand_once' turned off for newer versions).
> It can shortcut and say "ok, if it passes valid_array_reference, we should
> just consider the entire argument as one word as long as the final
> character is `]'." This is again where backwards compatibility and
> assoc_expand_once matter.
>
> We can apply your change, but it is still incomplete
What is exactly the incompleteness that you focus on in this context?
I understand that you are not satisfied with the behavior of the
backward-compatible mode, but once we define the design of the extra
expansions in the backward-compatible mode, I think this patch will
make it consistent and there is no incompleteness ``within'' the
backward-compatible mode.
> (plus it breaks things that currently work, like
>
> declare -A a
> key='$(echo foo)'
>
> a['$key']=2
> declare -p a
>
> unset -v "a['\$key']"
> declare -p a
>
> ).
This is related to another bug (which is rather a clear one) that has
existed since bash-4.0, for which I have a pending report. The above
problem is not caused by this patch, but just another bug that has
been concealed by the current behavior has been revealed. I was
planning to submit the report after this patch is processed because
the codes to be changed in two patches overlap with each other. Now
I'll submit the report though there are conflicting changes between
the two sets of patches.
> The real issue is that it's still going to expand the subscript for
> backwards compatibility. I think that's going to have to be solved
> at a higher level.
Yes, but I feel like this is another design issue which is irrelevant
for the fix of the present small problem.
--
Koichi
Re: [PATCH] devel: fix segfault by unset 'assoc[${x[0]}]'
On 10/5/21 7:05 AM, Koichi Murase wrote:
> The segmentation fault is fixed by the above patch, but there
> still remains the same error as bash 4.4.
>
> bash-patch1: ${x[0: bad substitution
>
> This is caused by an inconsistency between `valid_array_reference
> (name,flags)' (arrayfunc.c:1187) and `unbind_array_element
> (var,sub,flags)' (arrayfunc.c:1033) in the extraction of
> associative-array subscripts. Note that `valid_array_reference' is
> called from `unset_builtin' (builtins/set.def:834) to check if the
> unset name has the form of an array element. Also,
> `unbind_array_element' is called from `unset_builtin' to perform the
> actual unset. In `valid_array_reference', the length of the
> associative-array subscripts are determined as
>
> else if (isassoc)
> len = skipsubscript (t, 0, flags_NOEXPAND); /* VA_NOEXPAND
> must be 1 */
The difference is that valid_array_reference can be called before any of
the subscript is expanded, in which case you need to parse things that
can be expanded, where unbind_array_element is called after all the
expansions are performed (but see below).
So let's see if we can talk through this.
>
> whereas in `unbind_array_element', the length is determined as
>
> if (var && assoc_p (var) && (flags_ONEWORD))
> len = strlen (sub) - 1;
> else
> len = skipsubscript (sub, 0, (flags_NOEXPAND) || (var &&
> assoc_p(var))); /* XXX */
>
> `skipsubscript' does not consider the nesting of ${} and $() when
> bit 1 is set to the third argument. In the former code, nesting is
> not considered only when VA_NOEXPAND is specified. However, in the
> latter code, nesting is never considered for associative arrays
> (even when VA_NOEXPAND is not specified). I believe the former code
> should be the expected one.
You're right, there should be no `nesting' considered at all. By the time
unbind_array_element is called, since it's only called from unset_builtin,
the word and subscript should have already undergone all the expansion
they're going to. There should be no need to interpret ${} or $() in the
subscript: since associative arrays can have arbitrary subscripts, you
should not attempt to parse the subscript contents. That was obviously one
of the problems with the code through bash-5.1, one of the original reasons
I introduced `assoc_expand_once', and an issue that's still looking for a
final resolution.
However, there is backwards compatibility to consider, which is why
assoc_expand_once isn't set by default and the code attempts to run the
subscript through word expansion.
In this example, the quoting prevents the shell from recognizing the word
as an array reference before the quote removal occurs and the word gets
passed to the unset builtin, so it can't set any hints for unset. unset
sees `a[${b[0]}]', which is ambiguous.
It can shortcut and say "ok, if it passes valid_array_reference, we should
just consider the entire argument as one word as long as the final
character is `]'." This is again where backwards compatibility and
assoc_expand_once matter.
We can apply your change, but it is still incomplete (plus it breaks things
that currently work, like
declare -A a
key='$(echo foo)'
a['$key']=2
declare -p a
unset -v "a['\$key']"
declare -p a
). The real issue is that it's still going to expand the subscript for
backwards compatibility. I think that's going to have to be solved at a
higher level.
Maybe the unset builtin code should just punt as described above --
depending on the shell compatibility level -- and turn on
VA_ONEWORD|VA_NOEXPAND if there is an unquoted `[', the last character is a
`]', and valid_array_reference() returns true.
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/
Re: [PATCH] devel: fix segfault by unset 'assoc[${x[0]}]'
> In Bash 4.0--5.3, the unset command causes the following error:
>
> bash-4.0: [${x[0]}]: bad array subscript
Sorry, please ignore these two lines. This part is unrelated to the
fix of the patches. The above error message was produced for the empty
associative array key, which is the expected behavior. I just forgot
to remove these lines from the email draft before sending the mail.
--
Koichi
[PATCH] devel: fix segfault by unset 'assoc[${x[0]}]'
Bash Version:
devel branch (441078402919f6f0dd677cad18d55c7a89d294fc),
5.1.8(2)-maint (x86_64-pc-linux-gnu)
Description:
In the devel branch, « unset 'assoc[${x[0]}]' » causes a
segmentation fault, where `assoc' is the name of an associative
array. This does not happen with Bash 5.1.
In Bash 4.4--5.1, the same unset command causes the following
bad-substitution error:
bash-4.4: ${x[0: bad substitution
In Bash 4.0--5.3, the unset command causes the following error:
bash-4.0: [${x[0]}]: bad array subscript
Repeat-by:
The following command causes a segmentation fault.
$ bash-dev -c "declare -A a; unset 'a[\${b[0]}]'"
The stack trace reads
#0 0x77de4e35 in raise () from /lib64/libc.so.6
#1 0x77dcf895 in abort () from /lib64/libc.so.6
#2 0x00452fbf in programming_error ()
#3 0x004fd4d7 in internal_free.isra ()
#4 0x00474c10 in expand_word_internal.isra ()
#5 0x004774e0 in expand_subscript_string ()
#6 0x0048890a in unbind_array_element ()
#7 0x004b0ed5 in unset_builtin ()
#8 0x0043ad4b in execute_builtin.isra ()
#9 0x0043f69f in execute_command_internal ()
#10 0x00442ac3 in execute_connection ()
#11 0x0043dfd9 in execute_command_internal ()
#12 0x004a7191 in parse_and_execute ()
#13 0x00423f8b in run_one_command ()
#14 0x00422c0a in main ()
Fix:
The segmentation fault is caused in `expand_word_internal (WORD_DESC
*word, ...)' (subst.c:10325) which releases the memory block
`word->word' when it fails to expand the word. The problem is that
`expand_subscript_string (char *string, ...)' (subst.c:10184) tries
to directly pass the pointer `string' to `word->word' for the call
of `expand_word_internal (WORD_DESC *word, ...)'. `word->word' needs
to be a pointer which may be released on the expansion error.
* In the first patch `0001-patch', the argument string is copied
using `savestring ()', and the copy is passed to
`expand_word_internal' through `td.word'. Finally, the copy is
deleted by `free (td.word)'. When an expansion error occurs,
`NULL' is assigned to `fd.word' by `expand_word_internal', so
`free (td.word)'---i.e., `free (NULL)'---does nothing.
The segmentation fault is fixed by the above patch, but there
still remains the same error as bash 4.4.
bash-patch1: ${x[0: bad substitution
This is caused by an inconsistency between `valid_array_reference
(name,flags)' (arrayfunc.c:1187) and `unbind_array_element
(var,sub,flags)' (arrayfunc.c:1033) in the extraction of
associative-array subscripts. Note that `valid_array_reference' is
called from `unset_builtin' (builtins/set.def:834) to check if the
unset name has the form of an array element. Also,
`unbind_array_element' is called from `unset_builtin' to perform the
actual unset. In `valid_array_reference', the length of the
associative-array subscripts are determined as
else if (isassoc)
len = skipsubscript (t, 0, flags_NOEXPAND); /* VA_NOEXPAND
must be 1 */
whereas in `unbind_array_element', the length is determined as
if (var && assoc_p (var) && (flags_ONEWORD))
len = strlen (sub) - 1;
else
len = skipsubscript (sub, 0, (flags_NOEXPAND) || (var &&
assoc_p(var))); /* XXX */
`skipsubscript' does not consider the nesting of ${} and $() when
bit 1 is set to the third argument. In the former code, nesting is
not considered only when VA_NOEXPAND is specified. However, in the
latter code, nesting is never considered for associative arrays
(even when VA_NOEXPAND is not specified). I believe the former code
should be the expected one.
* In the second patch `0002-patch', the subscript extraction in
`unbind_array_element' is adjusted to match with that of
`valid_array_element'.
--
Koichi
0001-fix-unset-segfault-on-assoc-subscripts-with-paramexp.patch
Description: Binary data
0002-allow-nesting-and-quoting-in-assoc-subscripts-when-a.patch
Description: Binary data
Re: Infinite loop triggered by extglob +(!(x))y
On 7/25/21 5:01 PM, Andreas Schwab wrote: On Jul 25 2021, Chet Ramey wrote: In the bash build directory, for instance, it fails right away, as it should: there aren't any files ending in `y'. It doesn't matter whether the file name contains `y', just how long it is. That's not what I mean. It fails, as it should: there is no filename that will make it succeed. The runtime is obviously proportional to the length. -- ``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: Infinite loop triggered by extglob +(!(x))y
On Jul 25 2021, Chet Ramey wrote: > In the bash build directory, for instance, it fails right away, as it > should: there aren't any files ending in `y'. It doesn't matter whether the file name contains `y', just how long it is. Try creating a file with a name of 30 or more characters. Each additional character doubles the run time. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: Infinite loop triggered by extglob +(!(x))y
On 7/25/21 1:09 PM, andrej--- via Bug reports for the GNU Bourne Again SHell wrote: Bash Version: 5.1 Patch Level: 8 Release Status: release Description: An extglob like +(!(x))y causes Bash to freeze with a 100% CPU utilization. At the first glance the freeze doesn't seem to depend on the (non-)existence of matching paths. Repeat-By: echo +(!(x))y # This freezes! I can't reproduce this. This is a terribly inefficient pattern, and the behavior is proportional to the number of files and length of filenames. In the bash build directory, for instance, it fails right away, as it should: there aren't any files ending in `y'. In /tmp, with fewer files but longer filenames, it takes *much* longer. I agree that interactive shells could be more responsive to SIGINT. It's a question of checking for the flag the signal handler sets while executing the pattern matcher itself, rather than solely in the upper layers. This pattern spends a lot of time in a single call to strmatch(), which matches a single filename against a pattern, and the current code checks for SIGINT around calls to strmatch(). -- ``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: Infinite loop triggered by extglob +(!(x))y
On Jul 25 2021, Greg Wooledge wrote: > On Sun, Jul 25, 2021 at 07:09:50PM +0200, andrej--- via Bug reports for the > GNU Bourne Again SHell wrote: >> Description: >> An extglob like +(!(x))y causes Bash to freeze with a 100% CPU >> utilization. >> At the first glance the freeze doesn't seem to depend on the >> (non-)existence of matching paths. > > The files do seem to matter. > > unicorn:~/tmp$ echo +(!(x))y > servers-to-try > unicorn:~/tmp$ cd /tmp > unicorn:/tmp$ echo +(!(x))y > ^C^C^ZKilled It depends on the length of the existing file names. That pattern has quadratic complexity. > It's a really bad runaway, requiring SIGKILL from another terminal to > stop it. Not really. It's just that an interactive shell ignores or postpones a lot of signals during command execution. In a non-interactive shell, a simple SIGINT will stop it. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: Infinite loop triggered by extglob +(!(x))y
On Sun, Jul 25, 2021 at 07:09:50PM +0200, andrej--- via Bug reports for the GNU Bourne Again SHell wrote: > Description: > An extglob like +(!(x))y causes Bash to freeze with a 100% CPU > utilization. > At the first glance the freeze doesn't seem to depend on the > (non-)existence of matching paths. The files do seem to matter. unicorn:~/tmp$ echo +(!(x))y servers-to-try unicorn:~/tmp$ cd /tmp unicorn:/tmp$ echo +(!(x))y ^C^C^ZKilled It's a really bad runaway, requiring SIGKILL from another terminal to stop it.
Infinite loop triggered by extglob +(!(x))y
Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -march=x86-64 -mtune=generic -O2 -pipe -fno-plt -DDEFAULT_PATH_VALUE='/usr/local/sbin:/usr/local/bin:/usr/bin' -DSTANDARD_UTILS_PATH='/usr/bin' -DSYS_BASHRC='/etc/bash.bashrc' -DSYS_BASH_LOGOUT='/etc/bash.bash_logout' -DNON_INTERACTIVE_LOGIN_SHELLS uname output: Linux charon.podzimek.org 5.12.15-arch1-1-zen2 #1 SMP PREEMPT Sun, 11 Jul 2021 10:50:03 + x86_64 GNU/Linux Machine Type: x86_64-pc-linux-gnu Bash Version: 5.1 Patch Level: 8 Release Status: release Description: An extglob like +(!(x))y causes Bash to freeze with a 100% CPU utilization. At the first glance the freeze doesn't seem to depend on the (non-)existence of matching paths. Repeat-By: echo +(!(x))y # This freezes! echo y+(!(x)) # Yet this does *not* freeze. echo +(!(x))* # And this does *not* freeze. echo *+(!(x)) # And this does *not* freeze.
Re: declare -g -x in function does not get exported in this script - not on ubunto 20.04 and centos 8
On Wed, Jun 02, 2021 at 03:54:34PM -0600, v...@it4us.top wrote:
> --first script where declare -x -g works
> bar(){
>
> [[ $cnt == 1 ]] && declare -g -x nestedbug="not a nested variable-bug
> !!"
> }
>
> foo(){
> [[ $cnt == 1 ]] && bar && echo ${nestedbug:?"variable should be shown"}
> }
> foo
In this script, you're calling foo in the main shell process, and foo
calls bar, which sets the variable. All of this takes place within
a single process.
> --begin of not working script
>
> doOptions(){
> declare -g -x nestedbug="NOT BUG"
> return 0
> }
> doRun(){
> run=$( doOptions $* )
... and here, you are calling doOptions inside a subshell.
The variables that you create within the subshell vanish when the
subshell does. Even if you export them.
In the future, please try to create minimal examples that reproduce
the problem. I had to delete a *lot* of extraneous code.
declare -g -x in function does not get exported in this script - not on ubunto 20.04 and centos 8
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -g -O2 -fdebug-prefix-map=/build/bash-a6qmCk/bash-5.0=.
-fstack-protector-strong -Wformat -Werror=format-security -Wall
-Wno-parentheses -Wno-format-security
uname output: Linux ubandroid 5.8.0-53-generic #60~20.04.1-Ubuntu SMP Thu May 6
09:52:46 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu
Machine: aarch64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -g -O2 -fdebug-prefix-map=/build/bash-i8mNiV/bash-5.0=.
-fstack-protector-strong -Wformat -Werror=format-security -Wall
-Wno-parentheses -Wno-format-security
uname output: Linux it4us.top 5.4.0-1035-raspi #38-Ubuntu SMP PREEMPT Tue Apr
20 21:37:03 UTC 2021 aarch64 aarch64 aarch64 GNU/Linux
Machine Type: aarch64-unknown-linux-gnu
Bash Version: 5.0
Patch Level: 17
Release Status: release
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-redhat-linux-gnu'
-DCONF_VENDOR='redhat' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL
-DHAVE_CONFIG_H -I. -I. -I./include -I./lib -D_GNU_SOURCE -DRECYCLES_PIDS
-DDEFAULT_PATH_VALUE='/usr/local/bin:/usr/bin' -DSYSLOG_HISTORY -O2 -g -pipe
-Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS
-fexceptions -fstack-protector-strong -grecord-gcc-switches
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic
-fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection
-Wno-parentheses -Wno-format-security
uname output: Linux localhost.localdomain 4.18.0-240.22.1.el8_3.x86_64 #1 SMP
Thu Apr 8 19:01:30 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
Machine Type: x86_64-redhat-linux-gnu
Bash Version: 4.4
Patch Level: 19
Release Status: release
Description:
--first script where declare -x -g works
#!/usr/bin/bash
xas(){
[[ $cnt == 1 ]] && declare -g -x ThreeNestedbug="not a 3-nested
variable-bug !!"
[[ $cnt == 2 ]] && ThreeNestedbug=""
}
bar(){
[[ $cnt == 1 ]] && declare -g -x nestedbug="not a nested variable-bug
!!"
[[ $cnt == 2 ]] && nestedbug=""
xas
}
foo(){
[[ $cnt == 0 ]] && declare -g -x bug="not a variable-bug !!"
[[ $cnt == 1 ]] && bar && echo ${nestedbug:?"variable should be shown"}
[[ $cnt == 2 ]] && bar && echo ${nestedbug} " nestedbug variable should
be not shown"
[[ $cnt == 3 ]] && bug=""
}
cnt=0
foo
echo ${bug:?"variable should be shown"}
cnt=$(( $cnt + 1))
foo
echo ${ThreeNestedbug:?"variable should be shown"}
echo ${nestedbug:?"variable not shown"}
cnt=$(( $cnt + 1))
foo
echo ${ThreeNestedbug} "ThreeNestedbug variable should not be shown"
echo ${nestedbug} "variable not shown"
cnt=$(( $cnt + 1))
foo
echo ${bug:?"yes - variable should not be shown"}
-end of working script
--begin of not working script
#!/usr/bin/bash
doTrap(){
cd ${OPWD}
exit $1
}
doExit(){
bannerPrint $1
kill -15 $$
}
bannerPrint(){
printf "\n\n$*\n\n"
}
mkMasterKey(){
:
}
mkSubmissionMsg(){
submissionMsg="\n\
e-mail certificate request file ${PWD}/certreqs/${1}.${sExt}.csr.pem to $_WWW
service provider at $_EMAIL .\n\
If you did not receive and answer within a short time, your certificate might
have been rejected\n\
because of incorrect data, such as mismatched e-mail address, implausible
country or postal code.\n\
$_WWW needs to be able to contact certificate holder for security and business
reasons.\n\
Only the ${1} 'id' will be stored in the signed certificate.\n\
The remaining data stays in your certificate signig request (csr).\n\
It will be needed to sign additional future communication.\n\
Keep backed up!"
echo ${submissionMsg}
}
mkPersonalCsr(){
umask 0077
sExt=p
bannerPrint Generating CSR for ${2}
PS3="Enter corresponding number of chosen key - control-d (^D) to request a new
one: "
select key in $( ls -1 ${SAFE_STORE}/private/*.key.pem ); do break; done
#read -s -p "enter password for newly created key $key: " passw1 && export
passw1
if [[ "#${key}#" = "##" || ${key} = "0" ]]
then
key=$PWD/private/$2.${sExt}.key.pem
_key=$(basename $key)
openssl req -new -subject -newhdr ${passw1:+-passout env:passw1}
-verbose -subj "${1}/UID=skey:${_key}" -key
Re: set -x path always returns 1 on fedora34 on arm64
On 5/12/21 1:34 AM, Boleyn Su wrote: Please refer to the subject. To wrap the discussion, this appears to be a docker-container-only problem and the result of a bug in glibc. -- ``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: set -x path always returns 1 on fedora34 on arm64
good luck and wishes :) On Wed, May 12, 2021, 13:30 Boleyn Su wrote: > Totally agree. The OS is a customized one shipping a very old dockerd and > I am in no position to avoid using it. In fact, this is the very reason I > am using a Fedora container on top of it. > > Sent from https://boleyn.su/phone > > On Wed, May 12, 2021, 19:19 Boleyn Su wrote: > >> For running it on an arm64 pc, you can run docker load or something >> similar to load the image. The bug is not related to arm64 but the outdated >> container runtime on the arm64 pc I am using. You can check the link to the >> redhat bug tracker for more details. >> >> Sent from https://boleyn.su/phone >> >> On Wed, May 12, 2021, 19:05 Alex fxmbsw7 Ratchev >> wrote: >> >>> do you have instructions how to run the container >>> i have an a64 phone i wanted to try with termux ( and debian inside ) >>> but i dunno to spawn proot yet over the image, i think cause android fault >>> chroot is not enuff.. but ill try soon >>> >>> On Wed, May 12, 2021, 11:58 Boleyn Su wrote: >>> >>>> I just found someone facing the same issuse >>>> https://bugzilla.redhat.com/show_bug.cgi?id=1900021 >>>> >>>> On Wed, May 12, 2021, 17:25 Boleyn Su wrote: >>>> >>>> > I tested that it is the container image to blame by compiling the >>>> source >>>> > code from both the host and the container and checking that it only >>>> breaks >>>> > in the container. Maybe it is a libc bug or something. I will file a >>>> bug to >>>> > Fedora later. Would be great if anyone can test the image. Note that >>>> the >>>> > x86_64 image works as expected. >>>> > >>>> > >>>> > On Wed, May 12, 2021, 17:16 Andreas Kusalananda Kähäri < >>>> > andreas.kah...@abc.se> wrote: >>>> > >>>> >> On Wed, May 12, 2021 at 04:31:47PM +0800, Boleyn Su wrote: >>>> >> > Sorry, it is test -x instead of set -x. There are similar results >>>> for >>>> >> test >>>> >> > - r file, [ -r file] and so on. >>>> >> >>>> >> If "[ -r file]" is your code, then it fails because the "[" utility >>>> >> needs "]" as its last argument, and you are giving it "file]". >>>> Insert a >>>> >> space before that last "]". >>>> >> >>>> > That is just a typo. >>>> > >>>> >> If that is not the code you are using, then consider posting the code >>>> >> you are using. If you don't, we can only really say "it works for >>>> me". >>>> >> >>>> >> >>>> >> > >>>> >> > On Wed, May 12, 2021, 13:34 Boleyn Su wrote: >>>> >> > >>>> >> > > Please refer to the subject. >>>> >> > > >>>> >> >>>> >> -- >>>> >> Andreas (Kusalananda) Kähäri >>>> >> SciLifeLab, NBIS, ICM >>>> >> Uppsala University, Sweden >>>> >> >>>> >> . >>>> >> >>>> > >>>> >>>
Re: set -x path always returns 1 on fedora34 on arm64
Totally agree. The OS is a customized one shipping a very old dockerd and I am in no position to avoid using it. In fact, this is the very reason I am using a Fedora container on top of it. Sent from https://boleyn.su/phone On Wed, May 12, 2021, 19:19 Boleyn Su wrote: > For running it on an arm64 pc, you can run docker load or something > similar to load the image. The bug is not related to arm64 but the outdated > container runtime on the arm64 pc I am using. You can check the link to the > redhat bug tracker for more details. > > Sent from https://boleyn.su/phone > > On Wed, May 12, 2021, 19:05 Alex fxmbsw7 Ratchev > wrote: > >> do you have instructions how to run the container >> i have an a64 phone i wanted to try with termux ( and debian inside ) but >> i dunno to spawn proot yet over the image, i think cause android fault >> chroot is not enuff.. but ill try soon >> >> On Wed, May 12, 2021, 11:58 Boleyn Su wrote: >> >>> I just found someone facing the same issuse >>> https://bugzilla.redhat.com/show_bug.cgi?id=1900021 >>> >>> On Wed, May 12, 2021, 17:25 Boleyn Su wrote: >>> >>> > I tested that it is the container image to blame by compiling the >>> source >>> > code from both the host and the container and checking that it only >>> breaks >>> > in the container. Maybe it is a libc bug or something. I will file a >>> bug to >>> > Fedora later. Would be great if anyone can test the image. Note that >>> the >>> > x86_64 image works as expected. >>> > >>> > >>> > On Wed, May 12, 2021, 17:16 Andreas Kusalananda Kähäri < >>> > andreas.kah...@abc.se> wrote: >>> > >>> >> On Wed, May 12, 2021 at 04:31:47PM +0800, Boleyn Su wrote: >>> >> > Sorry, it is test -x instead of set -x. There are similar results >>> for >>> >> test >>> >> > - r file, [ -r file] and so on. >>> >> >>> >> If "[ -r file]" is your code, then it fails because the "[" utility >>> >> needs "]" as its last argument, and you are giving it "file]". >>> Insert a >>> >> space before that last "]". >>> >> >>> > That is just a typo. >>> > >>> >> If that is not the code you are using, then consider posting the code >>> >> you are using. If you don't, we can only really say "it works for >>> me". >>> >> >>> >> >>> >> > >>> >> > On Wed, May 12, 2021, 13:34 Boleyn Su wrote: >>> >> > >>> >> > > Please refer to the subject. >>> >> > > >>> >> >>> >> -- >>> >> Andreas (Kusalananda) Kähäri >>> >> SciLifeLab, NBIS, ICM >>> >> Uppsala University, Sweden >>> >> >>> >> . >>> >> >>> > >>> >>
Re: set -x path always returns 1 on fedora34 on arm64
I do not know how to run it on an Android phone either. BTW, I have fixed my issue by updating dockerd to v20.10.6 following the suggestion in the redhat bug tracker. Sent from https://boleyn.su/phone On Wed, May 12, 2021, 19:05 Alex fxmbsw7 Ratchev wrote: > do you have instructions how to run the container > i have an a64 phone i wanted to try with termux ( and debian inside ) but > i dunno to spawn proot yet over the image, i think cause android fault > chroot is not enuff.. but ill try soon > > On Wed, May 12, 2021, 11:58 Boleyn Su wrote: > >> I just found someone facing the same issuse >> https://bugzilla.redhat.com/show_bug.cgi?id=1900021 >> >> On Wed, May 12, 2021, 17:25 Boleyn Su wrote: >> >> > I tested that it is the container image to blame by compiling the source >> > code from both the host and the container and checking that it only >> breaks >> > in the container. Maybe it is a libc bug or something. I will file a >> bug to >> > Fedora later. Would be great if anyone can test the image. Note that the >> > x86_64 image works as expected. >> > >> > >> > On Wed, May 12, 2021, 17:16 Andreas Kusalananda Kähäri < >> > andreas.kah...@abc.se> wrote: >> > >> >> On Wed, May 12, 2021 at 04:31:47PM +0800, Boleyn Su wrote: >> >> > Sorry, it is test -x instead of set -x. There are similar results for >> >> test >> >> > - r file, [ -r file] and so on. >> >> >> >> If "[ -r file]" is your code, then it fails because the "[" utility >> >> needs "]" as its last argument, and you are giving it "file]". Insert >> a >> >> space before that last "]". >> >> >> > That is just a typo. >> > >> >> If that is not the code you are using, then consider posting the code >> >> you are using. If you don't, we can only really say "it works for me". >> >> >> >> >> >> > >> >> > On Wed, May 12, 2021, 13:34 Boleyn Su wrote: >> >> > >> >> > > Please refer to the subject. >> >> > > >> >> >> >> -- >> >> Andreas (Kusalananda) Kähäri >> >> SciLifeLab, NBIS, ICM >> >> Uppsala University, Sweden >> >> >> >> . >> >> >> > >> >
Re: set -x path always returns 1 on fedora34 on arm64
yea well i can only suggest using only newest versions, lower is nonsense On Wed, May 12, 2021, 13:15 Boleyn Su wrote: > I do not know how to run it on an Android phone either. BTW, I have fixed > my issue by updating dockerd to v20.10.6 following the suggestion in the > redhat bug tracker. > > Sent from https://boleyn.su/phone > > On Wed, May 12, 2021, 19:05 Alex fxmbsw7 Ratchev > wrote: > >> do you have instructions how to run the container >> i have an a64 phone i wanted to try with termux ( and debian inside ) but >> i dunno to spawn proot yet over the image, i think cause android fault >> chroot is not enuff.. but ill try soon >> >> On Wed, May 12, 2021, 11:58 Boleyn Su wrote: >> >>> I just found someone facing the same issuse >>> https://bugzilla.redhat.com/show_bug.cgi?id=1900021 >>> >>> On Wed, May 12, 2021, 17:25 Boleyn Su wrote: >>> >>> > I tested that it is the container image to blame by compiling the >>> source >>> > code from both the host and the container and checking that it only >>> breaks >>> > in the container. Maybe it is a libc bug or something. I will file a >>> bug to >>> > Fedora later. Would be great if anyone can test the image. Note that >>> the >>> > x86_64 image works as expected. >>> > >>> > >>> > On Wed, May 12, 2021, 17:16 Andreas Kusalananda Kähäri < >>> > andreas.kah...@abc.se> wrote: >>> > >>> >> On Wed, May 12, 2021 at 04:31:47PM +0800, Boleyn Su wrote: >>> >> > Sorry, it is test -x instead of set -x. There are similar results >>> for >>> >> test >>> >> > - r file, [ -r file] and so on. >>> >> >>> >> If "[ -r file]" is your code, then it fails because the "[" utility >>> >> needs "]" as its last argument, and you are giving it "file]". >>> Insert a >>> >> space before that last "]". >>> >> >>> > That is just a typo. >>> > >>> >> If that is not the code you are using, then consider posting the code >>> >> you are using. If you don't, we can only really say "it works for >>> me". >>> >> >>> >> >>> >> > >>> >> > On Wed, May 12, 2021, 13:34 Boleyn Su wrote: >>> >> > >>> >> > > Please refer to the subject. >>> >> > > >>> >> >>> >> -- >>> >> Andreas (Kusalananda) Kähäri >>> >> SciLifeLab, NBIS, ICM >>> >> Uppsala University, Sweden >>> >> >>> >> . >>> >> >>> > >>> >>
Re: set -x path always returns 1 on fedora34 on arm64
do you have instructions how to run the container i have an a64 phone i wanted to try with termux ( and debian inside ) but i dunno to spawn proot yet over the image, i think cause android fault chroot is not enuff.. but ill try soon On Wed, May 12, 2021, 11:58 Boleyn Su wrote: > I just found someone facing the same issuse > https://bugzilla.redhat.com/show_bug.cgi?id=1900021 > > On Wed, May 12, 2021, 17:25 Boleyn Su wrote: > > > I tested that it is the container image to blame by compiling the source > > code from both the host and the container and checking that it only > breaks > > in the container. Maybe it is a libc bug or something. I will file a bug > to > > Fedora later. Would be great if anyone can test the image. Note that the > > x86_64 image works as expected. > > > > > > On Wed, May 12, 2021, 17:16 Andreas Kusalananda Kähäri < > > andreas.kah...@abc.se> wrote: > > > >> On Wed, May 12, 2021 at 04:31:47PM +0800, Boleyn Su wrote: > >> > Sorry, it is test -x instead of set -x. There are similar results for > >> test > >> > - r file, [ -r file] and so on. > >> > >> If "[ -r file]" is your code, then it fails because the "[" utility > >> needs "]" as its last argument, and you are giving it "file]". Insert a > >> space before that last "]". > >> > > That is just a typo. > > > >> If that is not the code you are using, then consider posting the code > >> you are using. If you don't, we can only really say "it works for me". > >> > >> > >> > > >> > On Wed, May 12, 2021, 13:34 Boleyn Su wrote: > >> > > >> > > Please refer to the subject. > >> > > > >> > >> -- > >> Andreas (Kusalananda) Kähäri > >> SciLifeLab, NBIS, ICM > >> Uppsala University, Sweden > >> > >> . > >> > > >
Re: set -x path always returns 1 on fedora34 on arm64
I just found someone facing the same issuse https://bugzilla.redhat.com/show_bug.cgi?id=1900021 On Wed, May 12, 2021, 17:25 Boleyn Su wrote: > I tested that it is the container image to blame by compiling the source > code from both the host and the container and checking that it only breaks > in the container. Maybe it is a libc bug or something. I will file a bug to > Fedora later. Would be great if anyone can test the image. Note that the > x86_64 image works as expected. > > > On Wed, May 12, 2021, 17:16 Andreas Kusalananda Kähäri < > andreas.kah...@abc.se> wrote: > >> On Wed, May 12, 2021 at 04:31:47PM +0800, Boleyn Su wrote: >> > Sorry, it is test -x instead of set -x. There are similar results for >> test >> > - r file, [ -r file] and so on. >> >> If "[ -r file]" is your code, then it fails because the "[" utility >> needs "]" as its last argument, and you are giving it "file]". Insert a >> space before that last "]". >> > That is just a typo. > >> If that is not the code you are using, then consider posting the code >> you are using. If you don't, we can only really say "it works for me". >> >> >> > >> > On Wed, May 12, 2021, 13:34 Boleyn Su wrote: >> > >> > > Please refer to the subject. >> > > >> >> -- >> Andreas (Kusalananda) Kähäri >> SciLifeLab, NBIS, ICM >> Uppsala University, Sweden >> >> . >> >
Re: set -x path always returns 1 on fedora34 on arm64
I tested that it is the container image to blame by compiling the source code from both the host and the container and checking that it only breaks in the container. Maybe it is a libc bug or something. I will file a bug to Fedora later. Would be great if anyone can test the image. Note that the x86_64 image works as expected. On Wed, May 12, 2021, 17:16 Andreas Kusalananda Kähäri < andreas.kah...@abc.se> wrote: > On Wed, May 12, 2021 at 04:31:47PM +0800, Boleyn Su wrote: > > Sorry, it is test -x instead of set -x. There are similar results for > test > > - r file, [ -r file] and so on. > > If "[ -r file]" is your code, then it fails because the "[" utility > needs "]" as its last argument, and you are giving it "file]". Insert a > space before that last "]". > That is just a typo. > If that is not the code you are using, then consider posting the code > you are using. If you don't, we can only really say "it works for me". > > > > > > On Wed, May 12, 2021, 13:34 Boleyn Su wrote: > > > > > Please refer to the subject. > > > > > -- > Andreas (Kusalananda) Kähäri > SciLifeLab, NBIS, ICM > Uppsala University, Sweden > > . >
Re: set -x path always returns 1 on fedora34 on arm64
On Wed, May 12, 2021 at 04:31:47PM +0800, Boleyn Su wrote: > Sorry, it is test -x instead of set -x. There are similar results for test > - r file, [ -r file] and so on. If "[ -r file]" is your code, then it fails because the "[" utility needs "]" as its last argument, and you are giving it "file]". Insert a space before that last "]". If that is not the code you are using, then consider posting the code you are using. If you don't, we can only really say "it works for me". > > On Wed, May 12, 2021, 13:34 Boleyn Su wrote: > > > Please refer to the subject. > > -- Andreas (Kusalananda) Kähäri SciLifeLab, NBIS, ICM Uppsala University, Sweden .
Re: set -x path always returns 1 on fedora34 on arm64
i may can check it out later but dont count on it On Wed, May 12, 2021, 10:53 Boleyn Su wrote: > I know it is supposed to always work but it do break here. If anyone can > reproduce it would be more convincing though. I am using the Fedora 34 > container image from > https://dl.fedoraproject.org/pub/fedora/linux/releases/34/Container/aarch64/images/Fedora-Container-Base-34-1.2.aarch64.tar.xz > > On Wed, May 12, 2021, 16:37 Alex fxmbsw7 Ratchev > wrote: > >> i dunno but, -x is for exe flag and -r for readable, and it never did not >> work >> >> On Wed, May 12, 2021, 10:32 Boleyn Su wrote: >> >>> Sorry, it is test -x instead of set -x. There are similar results for >>> test >>> - r file, [ -r file] and so on. >>> >>> On Wed, May 12, 2021, 13:34 Boleyn Su wrote: >>> >>> > Please refer to the subject. >>> > >>> >>
Re: set -x path always returns 1 on fedora34 on arm64
I know it is supposed to always work but it do break here. If anyone can reproduce it would be more convincing though. I am using the Fedora 34 container image from https://dl.fedoraproject.org/pub/fedora/linux/releases/34/Container/aarch64/images/Fedora-Container-Base-34-1.2.aarch64.tar.xz On Wed, May 12, 2021, 16:37 Alex fxmbsw7 Ratchev wrote: > i dunno but, -x is for exe flag and -r for readable, and it never did not > work > > On Wed, May 12, 2021, 10:32 Boleyn Su wrote: > >> Sorry, it is test -x instead of set -x. There are similar results for test >> - r file, [ -r file] and so on. >> >> On Wed, May 12, 2021, 13:34 Boleyn Su wrote: >> >> > Please refer to the subject. >> > >> >
Re: set -x path always returns 1 on fedora34 on arm64
i dunno but, -x is for exe flag and -r for readable, and it never did not work On Wed, May 12, 2021, 10:32 Boleyn Su wrote: > Sorry, it is test -x instead of set -x. There are similar results for test > - r file, [ -r file] and so on. > > On Wed, May 12, 2021, 13:34 Boleyn Su wrote: > > > Please refer to the subject. > > >
Re: set -x path always returns 1 on fedora34 on arm64
Sorry, it is test -x instead of set -x. There are similar results for test - r file, [ -r file] and so on. On Wed, May 12, 2021, 13:34 Boleyn Su wrote: > Please refer to the subject. >
set -x path always returns 1 on fedora34 on arm64
Please refer to the subject.
Re: "unset x[0], a BASH bug?"
On Thu, May 06, 2021 at 10:42:36AM +0300, Oğuz wrote:
> 6 Mayıs 2021 Perşembe tarihinde Ulrich Windl <
> ulrich.wi...@rz.uni-regensburg.de> yazdı:
> >
> > But why is $# decremented after the first unset?
>
> Because `x[0]' existed then, and the number of x's members changed with its
> removal. `${#x[@]}' doesn't give you the top index of `x', it expands to
> the number of elements in `x'.
A helpful tip might be to use declare -p to show the array, instead of
simply echoing the values.
unicorn:~$ x=(1 2 3)
unicorn:~$ declare -p x
declare -a x=([0]="1" [1]="2" [2]="3")
unicorn:~$ unset 'x[0]'
unicorn:~$ declare -p x
declare -a x=([1]="2" [2]="3")
The other thing you need to watch out for is pathname expansion. x[0]
is a valid glob, and if you have a file named x0 in the current directory,
an unquoted x[0] will be expanded to x0, and then you'll be running
"unset x0" instead of what you intended.
Use quotes the way I showed in my example to avoid that issue.
Re: "unset x[0], a BASH bug?"
6 Mayıs 2021 Perşembe tarihinde Ulrich Windl <
ulrich.wi...@rz.uni-regensburg.de> yazdı:
>
> But why is $# decremented after the first unset?
>
Because `x[0]' existed then, and the number of x's members changed with its
removal. `${#x[@]}' doesn't give you the top index of `x', it expands to
the number of elements in `x'. I suspect you don't know that bash arrays
can be sparse. Well, they can be.
$ x=([42]=foo [69]=bar)
$ echo "${#x[@]}"
2
$ echo "${!x[@]}"
42 69
$ echo "${x[@]}"
foo bar
--
Oğuz
Re: "unset x[0], a BASH bug?"
6 Mayıs 2021 Perşembe tarihinde Ulrich Windl <
ulrich.wi...@rz.uni-regensburg.de> yazdı:
> Hi!
>
> Considering the example given in https://unix.stackexchange.
> com/a/648243/320598 I think it may be a bug, or an inappropriately
> documented feature.
>
> Basically:
> % x=(1 2 3)
> % echo "${#x[@]}"; echo "${x[@]}"
> 3
> 1 2 3
> % unset x[0]
> % echo "${#x[@]}"; echo "${x[@]}"
> 2
> 2 3
> % unset x[0]
> % echo "${#x[@]}"; echo "${x[@]}"
> 2
> 2 3
`unset x[0]' doesn't change indexes of other elements in `x'.
$ x=(1 2 3)
$ declare -p x
declare -a x=([0]="1" [1]="2" [2]="3")
$ unset x[0]
$ declare -p x
declare -a x=([1]="2" [2]="3")
And there is nothing in the documentation that suggests otherwise.
> % unset x[0]
> % echo "${#x[@]}"; echo "${x[@]}"
> 2
> 2 3
>
>
--
Oğuz
"unset x[0], a BASH bug?"
Hi!
Considering the example given in https://unix.stackexchange.com/a/648243/320598
I think it may be a bug, or an inappropriately documented feature.
Basically:
% x=(1 2 3)
% echo "${#x[@]}"; echo "${x[@]}"
3
1 2 3
% unset x[0]
% echo "${#x[@]}"; echo "${x[@]}"
2
2 3
% unset x[0]
% echo "${#x[@]}"; echo "${x[@]}"
2
2 3
% unset x[0]
% echo "${#x[@]}"; echo "${x[@]}"
2
2 3
