Re: No word splitting for assignment-like expressions in compound assignment
> On Jul 27, 2020, at 1:31 AM, Dale R. Worley wrote:
>
> Alexey Izbyshev writes:
>> I have a question about the following behavior:
>>
>> $ Z='a b'
>> $ A=(X=$Z)
>> $ declare -p A
>> declare -a A=([0]="X=a b")
>> $ A=(X$Z)
>> $ declare -p A
>> declare -a A=([0]="Xa" [1]="b")
>>
>> I find it surprising that no word splitting is performed in the first
>> compound assignment.
>
>> * Brace expansion is performed for "A=(X=a{x,y}b)" by all bash versions
>> mentioned above (which is inconsistent with normal variable assignment).
>> * Globbing for "A=(X=a?b)" is performed by bash 3.1.17, but not by other
>> versions.
>
> Interesting. The documentation for 4.2.53(1) says this about parameter
> assignments generally, with no special rules for compound assignments:
>
> All
> values undergo tilde expansion, parameter and variable expansion, com-
> mand substitution, arithmetic expansion, and quote removal (see EXPAN-
> SION below). ... Word splitting is not
> performed, with the exception of "$@" as explained below under Special
> Parameters. Pathname expansion is not performed.
>
> So it seems like the word splitting in "A=(X$Z)" is incorrect. So is
> pathname expansion in that context.
If word splitting were not performed in compound assignments, this...
foo=(a b c)
...would not work. If pathname expansion were not performed in compound
assignments, this...
foo=(*)
...would not work. Arrays would become significantly less usable if
word splitting and pathname expansion were not allowed in compound
assignments.
vq
Re: No word splitting for assignment-like expressions in compound assignment
On 2020-07-27 10:06, Lawrence Velázquez wrote: On Jul 27, 2020, at 1:31 AM, Dale R. Worley wrote: Interesting. The documentation for 4.2.53(1) says this about parameter assignments generally, with no special rules for compound assignments: All values undergo tilde expansion, parameter and variable expansion, com- mand substitution, arithmetic expansion, and quote removal (see EXPAN- SION below). ... Word splitting is not performed, with the exception of "$@" as explained below under Special Parameters. Pathname expansion is not performed. So it seems like the word splitting in "A=(X$Z)" is incorrect. So is pathname expansion in that context. If word splitting were not performed in compound assignments, this... foo=(a b c) ...would not work. If pathname expansion were not performed in compound assignments, this... foo=(*) ...would not work. Arrays would become significantly less usable if word splitting and pathname expansion were not allowed in compound assignments. To be clear, I don't consider word splitting and expansions in compound assignments to be a problem: this is well-known and long-standing behavior, even though it doesn't seem to be explicitly documented. In particular, I expect word splitting to happen in "A=(X$Z)" case. But I expect it to happen in "A=(X=$Z)" too, and the lack of it seems unintentional to me. Alexey
Re: No word splitting for assignment-like expressions in compound assignment
On Jul 27 2020, Lawrence Velázquez wrote: > If word splitting were not performed in compound assignments, this... > > foo=(a b c) > > ...would not work. This is not true. Field splitting is only relevant for words generated by other expansions, not for literal tokens. 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: No word splitting for assignment-like expressions in compound assignment
27 Temmuz 2020 Pazartesi tarihinde Alexey Izbyshev yazdı: > On 2020-07-27 10:06, Lawrence Velázquez wrote: > >> On Jul 27, 2020, at 1:31 AM, Dale R. Worley wrote: >>> Interesting. The documentation for 4.2.53(1) says this about parameter >>> assignments generally, with no special rules for compound assignments: >>> >>> All >>> values undergo tilde expansion, parameter and variable expansion, >>> com- >>> mand substitution, arithmetic expansion, and quote removal (see >>> EXPAN- >>> SION below). ... Word splitting is not >>> performed, with the exception of "$@" as explained below under >>> Special >>> Parameters. Pathname expansion is not performed. >>> >>> So it seems like the word splitting in "A=(X$Z)" is incorrect. So is >>> pathname expansion in that context. >>> >> >> >> If word splitting were not performed in compound assignments, this... >> >> foo=(a b c) >> >> ...would not work. If pathname expansion were not performed in compound >> assignments, this... >> >> foo=(*) >> >> ...would not work. Arrays would become significantly less usable if >> word splitting and pathname expansion were not allowed in compound >> assignments. >> >> To be clear, I don't consider word splitting and expansions in compound > assignments to be a problem: this is well-known and long-standing behavior, > even though it doesn't seem to be explicitly documented. In particular, I > expect word splitting to happen in "A=(X$Z)" case. But I expect it to > happen in "A=(X=$Z)" too, and the lack of it seems unintentional to me. I agree, anything that forms a valid assignment statement in isolation is exempt from word splitting and that indeed seems like a bug or very poor implementation choice. $ Z='a b' $ A=(X=$Z X[123]=$Z X[qwerty]=$Z X+=$Z) $ declare -p A declare -a A=([0]="X=a b" [1]="X[123]=a b" [2]="X[qwerty]=a b" [3]="X+=a b") > > Alexey > > -- Oğuz
Re: No word splitting for assignment-like expressions in compound assignment
On Mon, Jul 27, 2020 at 01:31:32AM -0400, Dale R. Worley wrote: > So it seems like the word splitting in "A=(X$Z)" is incorrect. If the documentation doesn't support word splitting in that case, then it's the documentation that will need to change, not the shell. Word splitting in that context is *frequently* used in scripts. Never mind the fact that it's dangerous and wrong -- people use it, a lot. A change to the shell that would stop it from occurring would break countless scripts.
Re: EOF not disabled in readline
On 7/24/20 1:32 AM, Grisha Levit wrote: > It seems that disabling the EOF character does not have an effect on > readline. No. Readline will bind a few of the special tty characters to their readline equivalents (controlled by the `bind-tty-special-chars' variable), but the EOF character is not one of them. What it does is to save the EOF character -- unless it's been disabled -- and special-case it as the first character read on an otherwise empty line. It defaults that character to ^D, which remains the default if the stty eof character is disabled. -- ``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: $SHELLOPTS after function with `local -'
On 7/24/20 2:14 AM, Grisha Levit wrote: > The value of $SHELLOPTS is not always updated correctly after returning > from a function that modifies options after using `local -'. Thanks for the report. I think this is an easy 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/
Re: $IGNOREEOF always modified by `local -'
On 7/24/20 2:25 AM, Grisha Levit wrote:
> Having IGNOREEOF defined prior to invoking a function that uses `local -'
> causes IGNOREEOF to be set to `10' after the function returns.
>
> $ IGNOREEOF=0; f() { local -; }; f; echo $IGNOREEOF
> 10
Yes, that's the default. `local -' saves the state of the option, not the
value of those options backed by variables (which just doesn't scale well).
--
``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: histexpand in shebang-less script
On 7/24/20 7:44 PM, Grisha Levit wrote: > The value of `histexpand' is not reset when executing a shebang-less > script. (Admittedly, this is unlikely to matter since the value of > `history' *is* properly reset.) > > $ cat > /tmp/test1.sh <<"EOF" > #!/usr/bin/env bash > echo $- > EOF > $ cat > /tmp/test2.sh <<"EOF" > echo $- > EOF > $ chmod +x /tmp/test1.sh /tmp/test2.sh > $ set -H > $ /tmp/test1.sh > hB > $ /tmp/test2.sh > hBH > > Since reset_shell_flags is only called in this circumstance, it seems > that turning off history expansion should be the right thing to do in > that function. 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/
Re: apparent inconsistencies in readline documentation
On 7/25/20 12:21 PM, Daniel Molina wrote: > Hi, > > I found some aspects of readline documentation that seem inconsistent to > me and I wanted to share them. > > 1. The difference between backward-kill-line and unix-line-discard > readline commands. > > Documentation states: > > backward-kill-line (C-x Rubout) > Kill backward to the beginning of the line. > > unix-line-discard (C-u) > Kill backward from point to the beginning of the > line. The > killed text is saved on the kill-ring. > > In both cases they kill from the point and killed text is saved in the > kill-ring. The difference is what happens with numeric arguments. Maybe that is what should be added to the backward-kill-line description. > > 2. Default key sequences vs. emacs key bindings [the default]. > > It is confusing to me that there are two defaults. Firstly, it can be read: > > EDITING COMMANDS > The following is a list of the names of the commands and > the default > key sequences to which they are bound. Command names without > an accom‐ > panying key sequence are unbound by default. > > On the other hand, emacs editing command are default: > > readline offers editing capabilities while the user is entering the > line. By default, the line editing commands are similar to > those of > emacs. A vi-style line editing interface is also available. > > An explicit list of emacs commands is maintained and commands do not > always coincide (both being valid defaults in practice). For example, > instead of C-x Rubout for backward-kill-line, emacs has > > "C-XC-?" backward-kill-line Rubout/DEL[ete]/C-? are the same key. > > 3. Key-bindings in the emacs/vi list are written with capital letters > (C-A), but not in the section with the description (C-a). It's a writing convention. The behavior doesn't differ. Are there places where this convention is used inconsistently? -- ``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: No word splitting for assignment-like expressions in compound assignment
> On Jul 27, 2020, at 4:02 AM, Andreas Schwab wrote: > > On Jul 27 2020, Lawrence Velázquez wrote: > >> If word splitting were not performed in compound assignments, this... >> >>foo=(a b c) >> >> ...would not work. > > This is not true. Field splitting is only relevant for words generated > by other expansions, not for literal tokens. My fault, I got it mixed up with tokenization. Carry on! vq
