segfaults with function attribute manipulations
A couple silly function attribute manipulations lead to situations that
result in segfaults:
$ f() { :; }; declare -Af f; declare -pf f
[ segfault ]
diff --git a/builtins/setattr.def b/builtins/setattr.def
index 251bcacb..1a828291 100644
--- a/builtins/setattr.def
+++ b/builtins/setattr.def
@@ -474,9 +474,9 @@ show_var_attributes (var, pattr, nodefs)
#if defined (ARRAY_VARS)
if (invisible_p (var) && (array_p (var) || assoc_p (var)))
printf ("%s\n", var->name);
- else if (array_p (var))
+ else if (array_p (var) && function_p (var) == 0)
print_array_assignment (var, 0);
- else if (assoc_p (var))
+ else if (assoc_p (var) && function_p (var) == 0)
print_assoc_assignment (var, 0);
else
#endif
(Maybe the better solution would be to prevent meaningless attributes from
getting assigned to functions in the first place, but they seem harmless
otherwise).
$ f() { :; }; declare +f -f f; declare -pf f
declare -- f=" "
$ f() { :; }; declare -Af f; declare +f -f f; unset -f f
[ segfault ]
diff --git a/builtins/declare.def b/builtins/declare.def
index 7eac6f58..bc44f54c 100644
--- a/builtins/declare.def
+++ b/builtins/declare.def
@@ -558,6 +558,7 @@ restart_new_var_name:
else /* declare -[fF] -[rx] name [name...] */
{
VSETATTR (var, flags_on);
+ flags_off &= ~att_function;
VUNSETATTR (var, flags_off);
}
}
Re: A small documentation suggestion
On Jan 07 2019, Keith Thompson wrote:
> I suggest documenting this behavior. It would be nice to be able to
> depend on the exact format, for example that ${EPOCHREALTIME/*./}
> is always exactly 6 digits long.
ms=${EPOCHREALTIME/*./}00
ms=${ms:0:6}
Andreas.
--
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
declaration of dollar_dollar_pid
Hello, Trying to install bash-5.0 and have error in 'make install' phase. $ uname -a SunOS hidden 5.11 11.3 i86pc i386 i86pc $ gcc --version gcc (GCC) 7.4.0 $ ./configure --prefix=/tmp/local CC=gcc CXX=g++ $ make $ make check $ make install : gcc -shared -Wl,-i -Wl,-h,sync -o sync sync.o gcc -fpic -DHAVE_CONFIG_H -DSHELL -DSOLARIS -g -O2 -Wno-parentheses -Wno-format-security -I. -I.. -I../.. -I../../lib -I../../builtins -I. -I../../include -I/tmp/bash-5.0 -I/tmp/bash-5.0/lib -I/tmp/bash-5.0/builtins -c -o push.o push.c push.c:38:12: error: conflicting types for 'dollar_dollar_pid' extern int dollar_dollar_pid; ^ In file included from ../../shell.h:31:0, from push.c:29: ../../variables.h:251:14: note: previous declaration of 'dollar_dollar_pid' was here extern pid_t dollar_dollar_pid; ^ make[1]: *** [Makefile:100: push.o] Error 1 make[1]: Leaving directory '/tmp/bash-5.0/examples/loadables' make: [Makefile:824: install] Error 2 (ignored) I wonder why it is not detected on 'make' or 'make check' phase. Anyway, can be fixed with --- sample fix from here --- diff -ur ../bash-5.0.orig/examples/loadables/push.c ./examples/loadables/push.c --- ../bash-5.0.orig/examples/loadables/push.c 2017-06-20 23:54:52.0 + +++ ./examples/loadables/push.c 2019-01-08 12:48:03.903548202 + @@ -35,7 +35,7 @@ extern int errno; #endif -extern int dollar_dollar_pid; +extern pid_t dollar_dollar_pid; extern int last_command_exit_value; int --- sample fix till here --- --- Kiyoshi
Re: [DOC] Incomplete explanation about the regex =~ operator
On Tue, Jan 08, 2019 at 10:47:21AM +, gilaro wrote: > See also: Does bash support word boundary regular expressions? Short answer: No. Long answer: Bash's =~ operator uses Extended Regular Expressions (ERE), as implemented by your system's C library's regular expression engine. Your system may or may not offer extensions beyond the standard POSIX definition of ERE. Any such extensions would by definition render your script non-portable, if you write code which relies on them. > I am trying to match on the presence of a word in a list before adding that > word again (to avoid duplicates). I ... Use an associative array instead of an indexed array. Associative arrays give you a natural, efficient way to determine whether an element is present in a set. If you also need to preserve the order of your list, then you may use both an indexed array (to preserve the order) AND an associative array (to check for existence efficiently).
Regexp string in := parameter expansion triggers failglob
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: x86_64-pc-linux-gnu-gcc
Compilation CFLAGS: -march=native -mtune=native -O2 -pipe -Wno-parentheses
-Wno-format-security
uname output: Linux abudhabi 4.19.13 #1 SMP PREEMPT Sat Dec 29 15:21:48 CET
2018 x86_64 AMD Opteron(tm) Processor 6328 AuthenticAMD GNU/Linux
Machine Type: x86_64-pc-linux-gnu
Bash Version: 5.0
Patch Level: 0
Release Status: release
Description:
When sourcing a script that contains a variable which performs
a := parameter expansion with a regular expression while failglob
shell option is enabled, bash-5.0 emits a "no match: "
error message.
Repeat-By:
> cat bash5_testscript.sh
: ${TESTPATTERN:="\(auto|unit\)\?tests\?"}
echo ${TESTPATTERN}
> shopt -s failglob
> source bash5_testscript.sh
bash: no match: \(auto|unit\)\?tests\?
bash: no match: \(auto|unit\)\?tests\?
>
Re: declaration of dollar_dollar_pid
On 1/7/19 11:21 PM, Kiyoshi KANAZAWA wrote: > Hello, > Trying to install bash-5.0 and have error in 'make install' phase. The loadables get installed into a local directory if you want to use them, but they're not essential to building bash or testing it, so they only get built on `make install'. -- ``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: Regexp string in := parameter expansion triggers failglob
On 1/8/19 8:35 AM, polynomia...@gentoo.org wrote:
> Bash Version: 5.0
> Patch Level: 0
> Release Status: release
>
> Description:
> When sourcing a script that contains a variable which performs
> a := parameter expansion with a regular expression while failglob
> shell option is enabled, bash-5.0 emits a "no match: "
> error message.
>
> Repeat-By:
> > cat bash5_testscript.sh
> : ${TESTPATTERN:="\(auto|unit\)\?tests\?"}
> echo ${TESTPATTERN}
>
> > shopt -s failglob
> > source bash5_testscript.sh
> bash: no match: \(auto|unit\)\?tests\?
> bash: no match: \(auto|unit\)\?tests\?
> >
Yes, that's the result of this change from back in April:
pathexp.c
- unquoted_glob_pattern_p: a pattern that contains a backslash can
have it removed by the matching engine (since backslash is special
in pattern matching), so if the pattern contains a backslash, and
does not end in a backslash, we need to return true. Fixes bug
reported by Robert Elz
The idea is that the backslash is special to shell pattern matching, and
the glob matching engine will remove it as part of filename expansion, so
patterns with backslashes are deemed to be subject to filename expansion
and therefore to `failglob'.
The bug report was something like (given the existence of a file named
'ab'):
var='a\b'
printf '<%s>\n' ${var}
what should the following print? Clearly $var expands to 'a\b', and, if
that string is passed to the matching engine unmodified as a pattern, the
backslash will be processed as an escape character and match the `b' in
`ab'.
And should the same thing happen when the file is named 'a?' and the
pattern is 'a\?'?
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: Regexp string in := parameter expansion triggers failglob
On Jan 08 2019, polynomia...@gentoo.org wrote:
> Description:
> When sourcing a script that contains a variable which performs
> a := parameter expansion with a regular expression while failglob
At this point it is just a random string, not a regular expression, and
the fact that := is used is irrelevant.
> shell option is enabled, bash-5.0 emits a "no match: "
At this point it is a glob pattern, not a regexp.
> echo ${TESTPATTERN}
If you don't want filename expansion, use quotes.
Andreas.
--
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
Re: Fwd: BASH_ARGV0 do not inherit from environment variables
On 1/8/19 1:47 AM, Cuong Manh Le wrote: > Hi, > > I'm not sure this a feature or bug, but: > > $ BASH_ARGV0=foo /usr/local/stow/bash/bin/bash -c 'echo "$0"' > /usr/local/stow/bash/bin/bash > > I expect $0 set to foo instead. Thanks for the suggestion. BASH_ARGV0 comes in as a feature suggested by the bash debugger, so it's what the debugger can use to replace the `set0' loadable builtin it includes. I'll keep this in mind for a future version. 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: A small documentation suggestion
Yes, you can do that, and it would be a good workaround *if*
$EPOCHREALTIME didn't already have 6 digits after the decimal point,
including any trailing zeros.
The point is that you don't have to, and I'm suggesting that the
documentation should make that clear so users can rely on it.
${EPOCHREALTIME: -6}
On Tue, Jan 8, 2019 at 2:13 AM Andreas Schwab wrote:
>
> On Jan 07 2019, Keith Thompson wrote:
>
> > I suggest documenting this behavior. It would be nice to be able to
> > depend on the exact format, for example that ${EPOCHREALTIME/*./}
> > is always exactly 6 digits long.
>
> ms=${EPOCHREALTIME/*./}00
> ms=${ms:0:6}
>
> Andreas.
>
> --
> Andreas Schwab, SUSE Labs, sch...@suse.de
> GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
> "And now for something completely different."
weird insert of backslashes in strings
Configuration Information [Automatically generated, do not change]:
Machine: i686
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -fstack-protector -Wno-parentheses -Wno-format-security
uname output: Linux bongo 2.6.32-042stab134.8 #1 SMP Fri Dec 7 17:16:09 MSK
2018 i686 i686 i386 GNU/Linux
Machine Type: i686-pc-linux-gnu
Bash Version: 5.0
Patch Level: 0
Release Status: release
Description:
This script "weirdbackslashes":
$ cat weirdbackslashes
#===begin
PRE='\/'
echo 'define'${PRE}'\
/'
#===end
produces with bash4:
$ bash weirdbackslashes
define\/\
/
and with bash5:
$ bash5 weirdbackslashes
\d\e\f\i\n\e\/\\\
/
Repeat-By:
see Description
Re: segfaults with function attribute manipulations
On 1/8/19 4:36 AM, Grisha Levit wrote:
> A couple silly function attribute manipulations lead to situations that
> result in segfaults:
Thanks for the report.
>
> $ f() { :; }; declare -Af f; declare -pf f
> [ segfault ]
>
> diff --git a/builtins/setattr.def b/builtins/setattr.def
> index 251bcacb..1a828291 100644
> --- a/builtins/setattr.def
> +++ b/builtins/setattr.def
> @@ -474,9 +474,9 @@ show_var_attributes (var, pattr, nodefs)
> #if defined (ARRAY_VARS)
>if (invisible_p (var) && (array_p (var) || assoc_p (var)))
> printf ("%s\n", var->name);
> - else if (array_p (var))
> + else if (array_p (var) && function_p (var) == 0)
> print_array_assignment (var, 0);
> - else if (assoc_p (var))
> + else if (assoc_p (var) && function_p (var) == 0)
> print_assoc_assignment (var, 0);
>else
> #endif
>
> (Maybe the better solution would be to prevent meaningless attributes from
> getting assigned to functions in the first place, but they seem harmless
> otherwise).
I prefer:
$ ./bash ./x19
./x19: line 1: declare: f: -A? Oh, come on.
f ()
{
:
}
--
``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: weird insert of backslashes in strings
On Tue, Jan 8, 2019, 3:10 PM Configuration Information [Automatically generated, do not change]:
> Machine: i686
> OS: linux-gnu
> Compiler: gcc
> Compilation CFLAGS: -fstack-protector -Wno-parentheses -Wno-format-security
> uname output: Linux bongo 2.6.32-042stab134.8 #1 SMP Fri Dec 7 17:16:09
> MSK 2018 i686 i686 i386 GNU/Linux
> Machine Type: i686-pc-linux-gnu
>
> Bash Version: 5.0
> Patch Level: 0
> Release Status: release
>
> Description:
> This script "weirdbackslashes":
>
> $ cat weirdbackslashes
> #===begin
> PRE='\/'
> echo 'define'${PRE}'\
> /'
> #===end
>
> produces with bash4:
> $ bash weirdbackslashes
> define\/\
> /
>
> and with bash5:
> $ bash5 weirdbackslashes
> \d\e\f\i\n\e\/\\\
> /
>
> Repeat-By:
> see Description
>
Reproduced. By the way, double quoting the variable eliminated the problem.
Re: "return" should not continue script execution, even if used inappropriately
> > df...@dfong.com said: > | there's a good reason for the "craziness": it enables individual > testing of > | the script's functions. > > For that kind of use there's a trivial solution (as there often > is for cases when people are sure that the current definition > is inadequate). > to be clear, i wasn't asking how to do it, i was only explaining why the "python craziness" is not crazy at all. > The one piece of advice from that python related BashFAQ that Greg > referred to which is worth following is ... > Bash can do this, but it's not a natural style, and you shouldn't be doing > it. to convincingly argue that "you shouldn't be doing this" requires more than a raw opinion backed by nothing but a completely subjective notion of "naturalness". i'd note that the cited page begins this premise: "There seem to be *two reasons* why people ask this: either they're trying to detect user errors and provide a friendly message, or they're Python programmers who want to use one of Python's most idiosyncratic features in bash." but the premise misses a powerful third reason. i'm not a "python programmer wanting to use an idiosyncratic feature of python", i'm a programmer who wants to write testable code. this so-called "unnatural" pattern from python makes the functions within a module testable without needing to write a wrapper script. this is a very practical and worthwhile advantage. to me, your suggested wrapper script pattern seems unnatural. i don't always want users to have to carry around 2 files (the dottable library and the wrapper to dot it in). this is, again, a practical disadvantage. it's just one more thing to break. speaking of breakage, i'd also note that your suggested pattern has a bug, it assumes that run-dotscr will only be run from the directory where the file lives. yes, the bug can be easily fixed. but fixing it will make your script a bit less "simple and natural". On Mon, Jan 7, 2019 at 5:47 PM Robert Elz wrote: > Date:Mon, 7 Jan 2019 08:55:58 -0500 > From:Greg Wooledge > Message-ID: <20190107135558.reqhfhr5vy3ih...@eeg.ccf.org> > > | https://mywiki.wooledge.org/BashFAQ/109 > > Which only works when the shell is bash... > > df...@dfong.com said: > | there's a good reason for the "craziness": it enables individual > testing of > | the script's functions. > > For that kind of use there's a trivial solution (as there often > is for cases when people are sure that the current definition > is inadequate). > > If you have a script "dotscr" and you want to test it, then > you do ... > > cat <<-EOF >run-dotscr > . ./dotscr > EOF > > and then > > sh run-dotscr # or bash, or mksh, or ... > > You can probably abbreviate that as > > sh -c '. ./dotscr' > > What's more, if dotscr is as most scripts designed to be used > via the . command, and has no actual executable code (in the > sense that it consumes no input and produces no output, so > aside from checking for syntax errors, the above does nothing > useful) you can add extra commands into the run-dotscr script; > or as extra commands after a ';' in the -c case, to actually call > the functions dotscr defines, or the variables it creates, or > whatever it does which needs testing. > > Or alternatively, interactively ... > > sh # start a new shell (any appropriate shell) > . ./dotscr > # do whatever testing you lile > exit > > Also, of course, it is also possible to write a script that can be > executed either via the '.' command, or as a standalone script, > if that is the desire - in fact many (perhaps most) scripts not > expressly designed to only work as "dot scripts" are like that. > > The one piece of advice from that python related BashFAQ that > Greg referred to which is worth following is ... > > Bash can do this, but it's not a natural style, > and you shouldn't be doing it. > > kre > > > >
