Re: hyphens (-) and underscores (_) are not treated as equivalent with completion-map-case and completion-ignore-case enabled
On 2021-01-19 22:32, Chet Ramey wrote: On 1/19/21 8:30 AM, aw...@cdak.net wrote: Bash Version: 5.1 Patch Level: 4 Release Status: release Description: man bash says: > completion-map-case (Off) > If set to On, and completion-ignore-case is enabled, readline treats hyphens (-) and underscores (_) as equivalent when performing case-insensitive filename matching and completion. $ bind -v|grep case set completion-ignore-case on set completion-map-case on Repeat-By: So it should be enabled and when I type $ touch _test $ chmod +x -t it completes to $ chmod +x _test But neither $ ./-t $ ls -t complete. If I turn off progcomp with `shopt -u progcomp` (as suggested here https://unix.stackexchange.com/questions/629844/bash-completion) it allows the `ls` example to complete but not the other. Thanks for the report. Those two options work for filename completion, but not command completion (the bulk of which is handled outside readline). I'll take a look at exposing that functionality outside readline, since it's currently part of readline's filename completion, but that will take some time and probably require a version bump. That's great, thank you for your efforts!
${a:=b} expands to `b', not `a''s value
$ declare -l a
$ echo "${a:=X} $a"
X x
This doesn't jive with what the manual says.
`-l`:
> When the variable is assigned a value, all upper-case characters are
converted to lower-case.
`:=`:
> If parameter is unset or null, the expansion of word is assigned to
parameter. The value of parameter is then substituted.
Is this a bug or am I missing something here?
--
Oğuz
Re: ${a:=b} expands to `b', not `a''s value
Le 20/01/2021 à 12:16, Oğuz écrivait :
$ declare -l a
$ echo "${a:=X} $a"
X x
This doesn't jive with what the manual says.
`-l`:
When the variable is assigned a value, all upper-case characters are
converted to lower-case.
`:=`:
If parameter is unset or null, the expansion of word is assigned to
parameter.
The assignation part:
a is assigned X but it is stored as x in a.
The value of parameter is then substituted.
The expansion part:
The value X is expanded but is not affected by the lowercase
transformation flag from a, so it remains as X.
The fact that an expansion also assign a value is a questionable design
choice though.
If I had to use this I would just silence the expansion as an argument
to the dummy true or : command
: ${a:=X}
Is this a bug or am I missing something here?
Then likely not.
--
Léa Gris
Re: ${a:=b} expands to `b', not `a''s value
On Jan 20 2021, Léa Gris wrote: >> The value of parameter is then substituted. > > The expansion part: > The value X is expanded but is not affected by the lowercase > transformation flag from a, so it remains as X. But that's not the value of the parameter. 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: ${a:=b} expands to `b', not `a''s value
Le 20/01/2021 à 13:51, Andreas Schwab écrivait : But that's not the value of the parameter. It is not, since at this point, the parameter has no value, the expansion expands the argument's value after ;= which is uppercase X here. -- Léa Gris
Re: ${a:=b} expands to `b', not `a''s value
On Jan 20 2021, Léa Gris wrote: > Le 20/01/2021 à 13:51, Andreas Schwab écrivait : >> But that's not the value of the parameter. > > It is not, since at this point, the parameter has no value, That is not true. Otherwise the expansion would be empty. > the expansion expands the argument's value after ;= which is uppercase > X here. No, the parameter has the value x. 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: ${a:=b} expands to `b', not `a''s value
20 Ocak 2021 Çarşamba tarihinde Léa Gris yazdı:
> Le 20/01/2021 à 12:16, Oğuz écrivait :
>
>> $ declare -l a
>> $ echo "${a:=X} $a"
>> X x
>>
>> This doesn't jive with what the manual says.
>>
>> `-l`:
>>
>>> When the variable is assigned a value, all upper-case characters are
>>>
>> converted to lower-case.
>>
>> `:=`:
>>
>>> If parameter is unset or null, the expansion of word is assigned to
>>>
>> parameter.
>>
>
> The assignation part:
> a is assigned X but it is stored as x in a.
>
> The value of parameter is then substituted.
>>
>
> The expansion part:
> The value X is expanded but is not affected by the lowercase
> transformation flag from a, so it remains as X.
>
The manual makes it explicit that it is `a''s value that is substituted,
not the value assigned to it, i.e X. I'd expect `${a:=X}' to expand to a
lowercase x there.
I filed a similar report here:
https://github.com/ksh93/ksh/issues/157
> The fact that an expansion also assign a value is a questionable design
> choice though.
>
> If I had to use this I would just silence the expansion as an argument to
> the dummy true or : command
>
> : ${a:=X}
>
> Is this a bug or am I missing something here?
>>
>
> Then likely not.
>
>
> --
> Léa Gris
>
>
>
--
Oğuz
Re: ${a:=b} expands to `b', not `a''s value
On 1/20/21 6:16 AM, Oğuz wrote:
$ declare -l a
$ echo "${a:=X} $a"
X x
This doesn't jive with what the manual says.
`-l`:
When the variable is assigned a value, all upper-case characters are
converted to lower-case.
`:=`:
If parameter is unset or null, the expansion of word is assigned to
parameter. The value of parameter is then substituted.
Is this a bug or am I missing something here?
Thanks for the report. It's probably not what you intend, but it's the way
bash has done things all the way back to bash-4.0 when the additional
variable attributes were introduced (and further back if you consider the
integer attribute).
The way bash does it is that the word is expanded (to `X') and that value
is assigned to a. That becomes the value of the expansion. The conversion
is then performed, at a lower layer, on the assignment.
This should only affect this particular parameter expansion involving
variables where this kind of conversion takes place at assignment time. I
think it would be reasonable to change the result to the final value of
the variable for the next version and make the new behavior dependent on
the shell compatibility level.
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:=b} expands to `b', not `a''s value
On Wed, Jan 20, 2021 at 6:44 PM Chet Ramey wrote: > Thanks for the report. It's probably not what you intend, but it's the way > bash has done things all the way back to bash-4.0 when the additional > variable attributes were introduced (and further back if you consider the > integer attribute). > The way bash does it is that the word is expanded (to `X') and that value > is assigned to a. That becomes the value of the expansion. The conversion > is then performed, at a lower layer, on the assignment. > > This should only affect this particular parameter expansion involving > variables where this kind of conversion takes place at assignment time. I > think it would be reasonable to change the result to the final value of > the variable for the next version and make the new behavior dependent on > the shell compatibility level. > I agree. Thanks > > 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/ >
