Re: Tilde expansion in assignment-like context
On 6.8. 22:45, Chet Ramey wrote: Yes. Bash has done this since its earliest days. A word that looks like an assignment statement has tilde expansion performed after unquoted =~ and :~ no matter where it appears on the command line. Given that options starting with a double-dashes (--something=/some/dir) are rather common, would it make sense to extend tilde expansion to apply in that case too? Of course, getopt_long() supports giving the option argument in a separate command-line argument, so you can work around it with that. Also, does the documentation actually say tilde expansion applies in anything that looks like an assignment? I can only see "If a word begins with an unquoted tilde character..." and "Each variable assignment is checked for unquoted tilde-prefixes...", but from the shell language point of view, the one in 'make DESTDIR=~stager/bash-install' isn't an assignment, just a regular command line argument. The paragraph about assignments could be expanded to say "This applies also to regular command-line arguments that look like assignments." or something like that. -- Ilkka Virta / itvi...@iki.fi
Re: delcare -a on a nameref in a function modifies nameref instead of target
A few more problematic test cases in this vein (tested against latest
devel snapshot 20180803).
f() { local -n ref=var; local -A ref=([1]=); ref=([2]=); declare -p ref var; }
unset ref var; f
# declare -An ref=()
# declare -A var=([1]="" )
declare -p ref
# declare -a ref=([2]="")
unset ref; var=0; f
# declare -An ref=([1]="" )
# declare -- var="0"
declare -p ref
# declare -a ref=([2]="")
f() { local -n ref=var; local -a ref=([1]=); ref=([2]=); declare -p ref var; }
unset ref var; f
# declare -an ref=()
# declare -a var=([1]="")
declare -p ref
# declare -a ref=([2]="")
unset ref; var=0; f
# declare -an ref=([1]="")
# declare -- var="0"
declare -p ref
# declare -a ref=([2]="")
# same issues for `local -[iluctrx] ref=...'
f() { local -n ref=var; local -i ref=([1]=); declare -p ref var; }
unset var; f
# declare -in ref="var"
# declare -ai var=([1]="0")
var=0; f
# declare -in ref="var"
# declare -a var=([1]="")
# same issue for `local -[ilucAa] ref=...'
f() { local -n ref=var; local ref=1; declare -p ref var; }; var=0; f
var=0; f
# bash: local: `1': invalid variable name for name reference
# declare -n ref="var"
# declare -- var="0"
Re: segfault w/ localvar_inherit and associative array insert
I don't know if this makes consistency easier or harder, but there is
currently code to handle `declare' with -[iluc] early [1]. As a result, a
combination of localvar_inherit and the use of one of those options when
declaring a local variable allows (correctly or not) for associative arrays
to inherit their previous value and have elements inserted at the same time:
$ declare -A A; A[X]=X
$ f() { local -u A+=([Y]=Y); declare -p A; }; f
declare -Au A=([X]="X" [Y]="Y" )
$ f() { local -u +u A+=([Y]=Y); declare -p A; }; f
declare -A A=([X]="X" [Y]="Y" )
$ f() { local A+=([Y]=Y); declare -p A; }; f
-bash: warning: A: cannot inherit value from incompatible type
[1]
https://git.savannah.gnu.org/cgit/bash.git/tree/subst.c?h=devel=057a9fbdb4d9ad01b000743fcea9918b80823afc#n11199
Re: Rational Range Interpretation for bash-5.0?
Chet Ramey wrote: > Hi. I am considering making bash glob expansion implement rational range > interpretation starting with bash-5.0 -- basically making globasciiranges > the default. It looks like glibc is going to do this for version 2.28 (at > least for a-z, A-Z, and 0-9), and other GNU utilities have done it for some > time. What do folks think? I think the non-rational ranges in libc were a terrible idea that we have all been suffering with over the last decade plus. Bob
Re: Rational Range Interpretation for bash-5.0?
On 08/06/2018 03:07 PM, Chet Ramey wrote: Hi. I am considering making bash glob expansion implement rational range interpretation starting with bash-5.0 -- basically making globasciiranges the default. It looks like glibc is going to do this for version 2.28 (at least for a-z, A-Z, and 0-9), and other GNU utilities have done it for some time. What do folks think? I'm in favor of the idea. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org
Rational Range Interpretation for bash-5.0?
Hi. I am considering making bash glob expansion implement rational range interpretation starting with bash-5.0 -- basically making globasciiranges the default. It looks like glibc is going to do this for version 2.28 (at least for a-z, A-Z, and 0-9), and other GNU utilities have done it for some time. What do folks think? 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: Tilde expansion in assignment-like context
> On 2018 Aug 6 , at 3:45 p, Chet Ramey wrote: > > On 8/6/18 3:09 PM, Clint Hepner wrote: > >> Bash Version: 4.4 >> Patch Level: 19 >> Release Status: release >> >> Description: >>A non-initial unquoted tilde is expanded outside of an assignment. >> This >>was raised as a question on Stack Overflow, >> https://stackoverflow.com/q/51713759/1126841. >> >> Repeat-By: >> >>$ set +k >>$ echo home_dir=~ >>home_dir=/Users/chepner > > Yes. Bash has done this since its earliest days. A word that looks like an > assignment statement has tilde expansion performed after unquoted =~ and :~ > no matter where it appears on the command line. This makes things like > > make DESTDIR=~stager/bash-install > or > export PATH=/usr/local/bin:~/bin:/usr/bin > > easy and convenient. Oh, right. For some reason, I had it in my head that this was only intended for builtins like export, and that their status as builtins somehow made the argument be treated as an assignment. I hadn't thought at all about non-builtin commands like make. > > The first version I can find that implemented the =~ and :~ tilde expansion > prefixes is bash-1.10 (1991). Those early versions would have expanded > something like `--home_dir=~'. The first version that restricted it to > words that satisfied the assignment statement restrictions is bash-2.0 > (1996). > > Bash doesn't do this when it's in posix mode. The first version that > implemented that was bash-1.14.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/
Re: Tilde expansion in assignment-like context
On 8/6/18 3:09 PM, Clint Hepner wrote: > Bash Version: 4.4 > Patch Level: 19 > Release Status: release > > Description: > A non-initial unquoted tilde is expanded outside of an assignment. > This > was raised as a question on Stack Overflow, > https://stackoverflow.com/q/51713759/1126841. > > Repeat-By: > > $ set +k > $ echo home_dir=~ > home_dir=/Users/chepner Yes. Bash has done this since its earliest days. A word that looks like an assignment statement has tilde expansion performed after unquoted =~ and :~ no matter where it appears on the command line. This makes things like make DESTDIR=~stager/bash-install or export PATH=/usr/local/bin:~/bin:/usr/bin easy and convenient. The first version I can find that implemented the =~ and :~ tilde expansion prefixes is bash-1.10 (1991). Those early versions would have expanded something like `--home_dir=~'. The first version that restricted it to words that satisfied the assignment statement restrictions is bash-2.0 (1996). Bash doesn't do this when it's in posix mode. The first version that implemented that was bash-1.14.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/
Tilde expansion in assignment-like context
Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: darwin16.7.0 Compiler: clang Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' -DCONF_OSTYPE='d\ arwin16.7.0' -DCONF_MACHTYPE='x86_64-apple-darwin16.7.0' -DCONF_VENDOR='apple' \ -DLOCALEDIR='/usr/local/Cellar/bash/4.4.19/share/locale' -DPACKAGE='bash' -DSHE\ LL -DHAVE_CONFIG_H -DMACOSX -I. -I. -I./include -I./lib -I./lib/intl -I/priv\ ate/tmp/bash-20180209-55597-111ek7c/bash-4.4/lib/intl -DSSH_SOURCE_BASHRC -Wno\ -parentheses -Wno-format-security uname output: Darwin hemma.local 16.7.0 Darwin Kernel Version 16.7.0: Thu Jun 2\ 1 20:07:39 PDT 2018; root:xnu-3789.73.14~1/RELEASE_X86_64 x86_64 Machine Type: x86_64-apple-darwin16.7.0 Bash Version: 4.4 Patch Level: 19 Release Status: release Description: A non-initial unquoted tilde is expanded outside of an assignment. This was raised as a question on Stack Overflow, https://stackoverflow.com/q/51713759/1126841. Repeat-By: $ set +k $ echo home_dir=~ home_dir=/Users/chepner A similar string that does not start with a valid identifier leaves the tilde unexpanded. $ echo --home_dir=~ --home_dir=~ The behavior is also present in commit 057a9fbdb4d9ad01b000743fcea9918b80823afc, bash-20180803 snapshot. Fix: [Description of how to fix the problem. If you don't know a fix for the problem, don't include this section.]
Re: bash brace issues (similar to shellshock)
> Find attached details regarding bash brace issues. King regards. What exactly is it that you think you've found? You have assignment statements preceding a command that is one component of a compound command. You might have a case that in the first three statements bash should throw an error at the assignment statement instead of treating it as if the operators were quoted (the result of parsing it like a possible compound assignment), but this certainly isn't anything close to a security problem. -- ``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: bash brace issues (similar to shellshock)
On 8/6/18 12:13 PM, Pierre Gaston wrote:
> On Mon, Aug 6, 2018 at 4:32 PM, martins dada
> wrote:
>
>> Find attached details regarding bash brace issues. King regards.
>>
>
> you are simply assigning (){ to a temporary environment before running the
> command
>
> $ n=(){ bash -c 'echo $n'
> (){
>
> just like:
>
> a=foo bash -c 'echo $a'
>
> I'd agree that I would not expect bash to accept this without quotes,
> but it does not allow to execute arbitrary commands like shellshock did.
> At least your examples don't show this.
Since bash parses the assignment as a possible compound array assignment,
it accepts the parens and doesn't throw an error. Once it discovers that
the statement doesn't qualify as a compound assignment, it has a choice:
it can go back and throw an error, or accept the assignment as if it were
quoted. It does the latter.
--
``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: bash brace issues (similar to shellshock)
On Mon, Aug 6, 2018 at 4:32 PM, martins dada
wrote:
> Find attached details regarding bash brace issues. King regards.
>
you are simply assigning (){ to a temporary environment before running the
command
$ n=(){ bash -c 'echo $n'
(){
just like:
a=foo bash -c 'echo $a'
I'd agree that I would not expect bash to accept this without quotes,
but it does not allow to execute arbitrary commands like shellshock did.
At least your examples don't show this.
Your third example is best understood if you move the redirection at the
end:
n=(){ a= date >\ echo
redirection can appear anywhere around the command
As your wrote it, it looks funny but it's not different from "date > file"
bash brace issues (similar to shellshock)
Find attached details regarding bash brace issues. King regards. bash Description: Binary data
Re: Rebinding forward-search-history causes lost of incremental behaviour
On 8/6/18 9:37 AM, Hugo Gabriel Eyherabide wrote: > Bash Version: 4.4 > Patch Level: 18 > Release Status: release > > Description: > > Rebinding forward-search-history through > bind '"\er": forward-search-history' > does trigger the function, but not incrementally as \C-s does (when pressed > repeatedly). Because ESC (\e) is still one of the characters that terminates an incremental search. The ESC terminates the search, but if you're quick enough with the r, it will be pushed and prefix a new key sequence. -- ``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/
Rebinding forward-search-history causes lost of incremental behaviour
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-unknown-linux-gnu' -DCONF_VENDOR='unknown' -DLOCALEDIR='/usr/local/share/locale$ uname output: Linux hugo-agile 4.13.0-43-generic #48~16.04.1-Ubuntu SMP Thu May 17 12:56:46 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux Machine Type: x86_64-unknown-linux-gnu Bash Version: 4.4 Patch Level: 18 Release Status: release Description: Rebinding forward-search-history through bind '"\er": forward-search-history' does trigger the function, but not incrementally as \C-s does (when pressed repeatedly).
bind -u not working for keyseq starting with \e
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-unknown-linux-gnu' -DCONF_VENDOR='unknown' -DLOCALEDIR='/usr/local/share/locale$ uname output: Linux hugo-agile 4.13.0-43-generic #48~16.04.1-Ubuntu SMP Thu May 17 12:56:46 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux Machine Type: x86_64-unknown-linux-gnu Bash Version: 4.4 Patch Level: 18 Release Status: release Description: bind -u not working for keyseq starting with \e Repeat-By: # Shows two keyseq, one starting with \C, the other with \e $ bind -p | grep forward-search-history | grep -v \# "\C-t": forward-search-history "\en": non-incremental-forward-search-history # Attempt to erase the one starting with \C using bind -u $ bind -u forward-search-history $ bind -p | grep forward-search-history | grep -v \# "\en": non-incremental-forward-search-history # It worked! # Attempt to erase the one starting with \e using bind -u hugo@hugo-agile:~$ bind -u non-incremental-forward-search-history hugo@hugo-agile:~$ bind -p | grep forward-search-history | grep -v \# "\en": non-incremental-forward-search-history # It did not work! The problem occurs with other functions as well.
Re: Improper handling of \! and \( while using Bash V4.1.2
On Mon, Aug 06, 2018 at 04:14:49PM +0530, anant garg wrote: > $ mode=! > $ [ "$mode" != "ro" -a "$mode" != "rw" ] && echo OK > + '[' '!' '!=' ro -a '!' '!=' rw ']' > bash: [: too many arguments The use of -a and -o as conjunctions inside a test or [ command is to be avoided. It's not POSIX compatible, and as you have now observed first-hand, even in bash, it is perilous. For this particular check, I would use case: case $mode in ro|rw) ;; *) ;; esac But if for some reason you've got an if-boner, you could either use two separate test commands: if [ "$mode" != ro ] && [ "$mode" != rw ] or use bash's [[ command: if [[ $mode != ro && $mode != rw ]] The former is POSIX comptaible. The latter is, of course, a bash extension.
Improper handling of \! and \( while using Bash V4.1.2
Hi , I am using the below environment. Linux kernel :- kernel-2.6.32-504.16.2.el6.x86_64 Bash version :- bash-4.1.2-29.x86_64 In our production code, one test related to parameter validation failed as below :- $ mode=! $ [ "$mode" != "ro" -a "$mode" != "rw" ] && echo OK + '[' '!' '!=' ro -a '!' '!=' rw ']' bash: [: too many arguments I checked the source and found that when multiple checks are done in one single test expression then ! parsing fails. For eg, the below works :- $ mode=! $ [ "$mode" != "ro" ] && echo OK OK The below also works :- $ mode=\! $ [ "$mode" != "ro" ] && echo OK OK The below also works :- $ mode=\( $ [ "$mode" != "ro" ] && echo OK OK but when below is run where multiple conditions are tested, then the parsing fails. For eg:- mode=\( [ "$mode" != "ro" -a "$mode" != "rw" ] && echo OK bash: [: `)' expected, found ro I tried testing with other special characters as well, but this issue came with only !,\! or \(. When I tested with extended test i.e [[ , this issue did not came. Was there any known bug in Bash V4.1.2 related to parsing of multiple ! or \( in [.
[PATCH] Re-display prompt if directory changed in a bind -x command
Using bind -x to call cd or source a script that changes the directory
will not update the prompt to show the new directory after the script
finished:
user@host:~$ bind -x '"\C-t": "echo test;cd /"'
# I press Ctrl-T
test
user@host:~$
Prompt still shows ~ as the pwd. Once I press Return or Ctrl-L the
prompt shows root as the pwd.
Updating the prompt is useful when using the mc-wrapper.sh script for
Midnight Commander that changes the bash pwd to the last mc directory
when mc exits. There is a similar wrapper for vim for example.
Attached patch decodes the prompt string again after running the
command passed to bind -x.
Regards,
Bogdan
--- a/bashline.c 2017-01-20 21:22:01.0 +0200
+++ b/bashline.c 2018-08-06 10:05:31.670533840 +0300
@@ -55,6 +55,7 @@
#include "shmbutil.h"
#include "trap.h"
#include "flags.h"
+#include "externs.h" /* decode_prompt_string() */
#if defined (HAVE_MBSTR_H) && defined (HAVE_MBSCHR)
# include /* mbschr */
@@ -4066,6 +4067,8 @@
#endif
}
+extern char *current_readline_prompt;
+
static int
bash_execute_unix_command (count, key)
int count; /* ignored */
@@ -4122,6 +4125,11 @@
save_parser_state ();
r = parse_and_execute (cmd, "bash_execute_unix_command", SEVAL_NOHIST|SEVAL_NOFREE);
restore_parser_state ();
+
+ /* current dir may have changed, decode prompt again */
+ FREE (current_readline_prompt);
+ current_readline_prompt = decode_prompt_string (current_prompt_string);
+ rl_expand_prompt (current_readline_prompt);
v = find_variable ("READLINE_LINE");
l1 = v ? value_cell (v) : 0;
