Equivalence classes handled differently in mb vs non-mb patterns
Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnux32 Compiler: gcc-10.1.0 -mx32 Compilation CFLAGS: -O2 -Wno-parentheses -Wno-format-security uname output: Linux loucetios 5.7.9 #1 SMP @1590968955 x86_64 GNU/Linux Machine Type: x86_64-pc-linux-gnux32 Bash Version: 5.0 Patch Level: 18 Release Status: release Description: In lib/glob/smatch.c, there are two functions that are used to check equivalence classes in patterns: collequiv, and collequiv_wc. The former is used if the pattern does not contain any multi-byte characters, the latter otherwise, With exceptions that are not relevant to this bug. The two functions do not give the same results: collequiv does not implement the fnmatch() fallback code that collequiv_wc does implement, leading to inconsistent matching for ASCII-only equivalence classes. (This is not something I encountered in a real script. I am implementing equivalence class support myself, using fnmatch() as the main check rather than as a fallback, and comparing the results to those of other shells.) Repeat-By: case a in [[=A=]]) echo match 1 ;; esac case aá in [[=A=]]á) echo match 2 ;; esac In locales where A and a are not in the same equivalence class, this should print nothing. glibc's ja_JP.UTF-8 is such a locale. The C locale is such a locale as well, but it does not allow for the á character, so may be bad for testing. In locales where A and a are in the same equivalence class, this should print "match 1" and "match 2". glibc's en_US.UTF-8 is such a locale. What actually happens in glibc's en_US.UTF-8 locale is that only "match 2" is printed. Fix: Copy the FNMATCH_EQUIV_FALLBACK logic from collequiv_wc to collequiv. _fnmatch_fallback_wc may be copied to create a non-wc version of it, but it also works to have collequiv call _fnmatch_fallback_wc by converting characters to wide characters.
Re: apparent inconsistencies in readline documentation
On 27/7/20 22:09, Chet Ramey wrote: > 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. I see. > Maybe that is what > should be added to the backward-kill-line description. I think that would be useful for that an similar commands. I found the question asked on the web too. >> 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. I see. >> 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? > Convention is not followed strictly in the same document doc/readline.0, but I suppose that it is intentional to keep a different convention in the DEFAULT KEY BINDINGS (emacs and vi list) where uppercase is used, and the rest of the document, where mainly lower case is used with very few exceptions: In SEARCHING: If that variable has not been assigned a value the Escape and C-J characters will terminate an incremental search. C-G will abort an incremental search and restore the original line. In INITIALIZATION FILE -> Variables isearch-terminators (``C-[ C-J'') The string of characters that should terminate an incremental search without subsequently executing the character as a com‐ mand. If this variable has not been given a value, the charac‐ ters ESC and C-J will terminate an incremental search. Maybe a confusing part is Section "1.3.3 Sample Init File" of doc/readline.info where there are lines like # Arrow keys in keypad mode # #"\M-OD": backward-char # # Arrow keys in ANSI mode # "\M-[D": backward-char and "\C-xr": redraw-current-line but in that case maybe it is not a convention but a parsing rule of INITRC (?), I do not understand well the conventions in that section. Regards, Daniel
warning: the use of `mktemp' is dangerous, better use `mkstemp' or `mkdtemp'
Hi, On Ubuntu 20.04, I try to compile the git master version of bash with the followin steps: $ sudo apt-get build-dep bash $ git clone https://git.savannah.gnu.org/git/bash.git bash.git $ cd bash.git $ ./configure $ make -j44 [...] /usr/bin/ld: ./lib/sh/libsh.a(tmpfile.o): in function `sh_mktmpname': /home/werner/Public/repo/git.savannah.gnu.org/git/bash.git/lib/sh/tmpfile.c:152: warning: the use of `mktemp' is dangerous, better use `mkstemp' or `mkdtemp' [...] Any hints for fix this warning? Regards -- Hongyi Zhao
`help declare' don't show the same document with the online one.
Hi, On Ubuntu 20.04, I installed the latest git master version of bash. Then I check the document for declare built-in command and also check the online document located here: https://www.gnu.org/software/bash/manual/bash#Bash-Builtins. The online version of the document for declare told the following usage: declare declare [-aAfFgilnrtux] [-p] [name[=value] …] [...] The -p option will display the attributes and values of each name. When -p is used with name arguments, additional options, other than -f and -F, are ignored. But I can't find the same notes from the local version of the document for this command given by `help declare', any hints for this problem? Regards -- Hongyi Zhao
Re: warning: the use of `mktemp' is dangerous, better use `mkstemp' or `mkdtemp'
On 7/28/20 8:19 AM, Hongyi Zhao wrote: > Hi, > > On Ubuntu 20.04, I try to compile the git master version of bash with > the followin steps: > > $ sudo apt-get build-dep bash > $ git clone https://git.savannah.gnu.org/git/bash.git bash.git > $ cd bash.git > $ ./configure > $ make -j44 > [...] > /usr/bin/ld: ./lib/sh/libsh.a(tmpfile.o): in function `sh_mktmpname': > /home/werner/Public/repo/git.savannah.gnu.org/git/bash.git/lib/sh/tmpfile.c:152: > warning: the use of `mktemp' is dangerous, better use `mkstemp' or > `mkdtemp' > [...] > > > Any hints for fix this warning? It's a spurious warning, with no apparent way to disable. The warning assumes that you immediately want a file descriptor or a directory, but provides no way to indicate that you are going to follow with mkfifo(). If you're going to do that, the warning is just wrong. -- ``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: `help declare' don't show the same document with the online one.
> The online version of the document for declare told the following usage: > > > declare > declare [-aAfFgilnrtux] [-p] [name[=value] …] > [...] > The -p option will display the attributes and values of each name. > When -p is used with name arguments, additional options, other than -f > and -F, are ignored. > > > But I can't find the same notes from the local version of the document > for this command given by `help declare', any hints for this problem? The help text built into bash is a much shorter version of the manual text. It's intended to be a hint, with the man page providing the detail. -- ``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/28/20 4:21 AM, Daniel Molina wrote:
> On 27/7/20 22:09, Chet Ramey wrote:
>> 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.
>
>
> I see.
>
>
>> Maybe that is what
>> should be added to the backward-kill-line description.
>
> I think that would be useful for that an similar commands. I found the
> question asked on the web too.
There is already
"If you pass a negative argument to a
command which normally acts in a forward direction, that command will
act in a backward direction. For example, to kill text back to the
start of the line, you might type @samp{M-- C-k}."
It seems like one statement is better than adding the same text to
multiple command descriptions.
> Maybe a confusing part is Section "1.3.3 Sample Init File" of
> doc/readline.info where there are lines like
>
> # Arrow keys in keypad mode
> #
> #"\M-OD": backward-char
>
>
> #
> # Arrow keys in ANSI mode
> #
> "\M-[D": backward-char
>
> and
>
> "\C-xr": redraw-current-line
This is not what we're talking about. These are specific multi-key
sequences that are bound to specific commands, not a question of whether
C-A and C-a are equivalent. The parallel to the previous question would
be whether "\C-Xr" and "\C-xr" are equivalent key sequences.
--
``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 7/23/20 8:11 PM, Alexey Izbyshev wrote: > Hello! > > 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. I realize that skipping word splitting may be > desirable if a subscript is given (e.g. "A=([0]=$Z)") to make it consistent > with normal variable assignment[1], but in this case it looks like a bug. It's an assignment statement in a context where assignment statements are accepted (which is what makes it different from `echo X=$Z', for instance), but the lack of a subscript on the lhs makes it a special case. I'll take a look at the semantics here. -- ``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: `help declare' don't show the same document with the online one.
On Tue, Jul 28, 2020 at 9:25 PM Chet Ramey wrote: > > > > The online version of the document for declare told the following usage: > > > > > > declare > > declare [-aAfFgilnrtux] [-p] [name[=value] …] > > [...] > > The -p option will display the attributes and values of each name. > > When -p is used with name arguments, additional options, other than -f > > and -F, are ignored. > > > > > > But I can't find the same notes from the local version of the document > > for this command given by `help declare', any hints for this problem? > > The help text built into bash is a much shorter version of the manual > text. It's intended to be a hint, with the man page providing the detail. Thanks a lot for your help. I rechecked the man page with the following command and confirmed the comments you told above: $ man bash | egrep -A10 '^[ ]*declare \[' declare [-aAfFgilnrtux] [-p] [name[=value] ...] typeset [-aAfFgilnrtux] [-p] [name[=value] ...] Declare variables and/or give them attributes. If no names are given then display the values of variables. The -p option will display the attributes and values of each name. When -p is used with name arguments, additional options, other than -f and -F, are ig‐ nored. -- Hongyi Zhao
Re: No word splitting for assignment-like expressions in compound assignment
On 28.7. 17:22, Chet Ramey wrote:
On 7/23/20 8:11 PM, Alexey Izbyshev wrote:
$ Z='a b'
$ A=(X=$Z)
$ declare -p A
declare -a A=([0]="X=a b")
It's an assignment statement in a context where assignment statements are
accepted (which is what makes it different from `echo X=$Z', for instance),
but the lack of a subscript on the lhs makes it a special case. I'll take a
look at the semantics here.
This is also a bit curious:
$ b=( [123]={a,b,c}x )
$ declare -p b
declare -a b=([0]="[123]=ax" [1]="[123]=bx" [2]="[123]=cx")
It does seem to have a subscript on the LHS, but it didn't work as one.
To be in line with a plain scalar assignment, the braces should probably
not be expanded here.
--
Ilkka Virta / itvi...@iki.fi
Re: No word splitting for assignment-like expressions in compound assignment
On 7/28/20 4:14 PM, Ilkka Virta wrote:
> On 28.7. 17:22, Chet Ramey wrote:
>> On 7/23/20 8:11 PM, Alexey Izbyshev wrote:
>>> $ Z='a b'
>>> $ A=(X=$Z)
>>> $ declare -p A
>>> declare -a A=([0]="X=a b")
>
>> It's an assignment statement in a context where assignment statements are
>> accepted (which is what makes it different from `echo X=$Z', for instance),
>> but the lack of a subscript on the lhs makes it a special case. I'll take a
>> look at the semantics here.
>
> This is also a bit curious:
>
> $ b=( [123]={a,b,c}x )
> $ declare -p b
> declare -a b=([0]="[123]=ax" [1]="[123]=bx" [2]="[123]=cx")
>
> It does seem to have a subscript on the LHS, but it didn't work as one.
> To be in line with a plain scalar assignment, the braces should probably
> not be expanded here.
Thanks, I'll look at it.
--
``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/
Bug Report concerning backslash in bash5
Hello GNU team, I found this misbehaviour in Bash 5 (e.g. GNU bash, version 5.0.16(1)-release (x86_64-pc-linux-gnu)): $ BLA="1\.2"; echo 'x/'$BLA'/y/' \x/1\.2/\y/ I don't see any reasonable reason for the generated backslashes here. Compare to bash 4 (e.g. GNU bash, version 4.4.12(1)-release (arm-unknown-linux-gnueabihf)): $ BLA="1\.2"; echo 'x/'$BLA'/y/' x/1\.2/y/ I found some discussion around this bug, but it seems not to be finally fixed: https://lists.gnu.org/archive/html/bug-bash/2019-01/msg00087.html Thanks for checking and fixing this in advance, regards, Ralph Beckmann (from Germany)
Re: Bug Report concerning backslash in bash5
Ralph Beckmann writes: > I found this misbehaviour in Bash 5 (e.g. GNU bash, version > 5.0.16(1)-release (x86_64-pc-linux-gnu)): > > $ BLA="1\.2"; echo 'x/'$BLA'/y/' > \x/1\.2/\y/ > > I don't see any reasonable reason for the generated backslashes here. My guess is that you're running into the fact that there are two types of quoting character. One quotes *any* character that follows it, and thus it never appears in "the output" unless it was doubled in the input. The other type *only* quotes characters that are somewhow special in that particular context. Reading the manual page: Enclosing characters in double quotes preserves the literal value of all characters within the quotes, with the exception of $, `, \, and, when history expansion is enabled, !. The characters $ and ` retain their special meaning within double quotes. The backslash retains its special meaning only when followed by one of the following characters: $, `, ", \, or . So backslash-inside-double-quotes-in-bash is of the second type, it only quotes things that would otherwise be special. So the value of $BLA is 1-\-.-2, whereas if the period was replaced by $, $BLA would only have 3 characters: $ BLA="1\$2"; echo 'x/'$BLA'/y/' x/1$2/y/ Dale
Re: Bug Report concerning backslash in bash5
On 7/29/20 1:35 AM, Dale R. Worley wrote: > Ralph Beckmann writes: >> I found this misbehaviour in Bash 5 (e.g. GNU bash, version >> 5.0.16(1)-release (x86_64-pc-linux-gnu)): >> >> $ BLA="1\.2"; echo 'x/'$BLA'/y/' >> \x/1\.2/\y/ >> >> I don't see any reasonable reason for the generated backslashes here. > > My guess is that you're running into the fact that there are two types > of quoting character. One quotes *any* character that follows it, and > thus it never appears in "the output" unless it was doubled in the > input. The other type *only* quotes characters that are somewhow > special in that particular context. Reading the manual page: > >Enclosing characters in double quotes preserves the literal value of >all characters within the quotes, with the exception of $, `, \, and, >when history expansion is enabled, !. The characters $ and ` retain >their special meaning within double quotes. The backslash retains its >special meaning only when followed by one of the following characters: >$, `, ", \, or . > > So backslash-inside-double-quotes-in-bash is of the second type, it only > quotes things that would otherwise be special. So the value of $BLA is > 1-\-.-2, whereas if the period was replaced by $, $BLA would only have 3 > characters: > > $ BLA="1\$2"; echo 'x/'$BLA'/y/' > x/1$2/y/ > I'm not sure what point you're trying to make here. Are you arguing that *printing* these backslash escapes is valid behavior here, and the reporter has merely misunderstood the shell rules? -- Eli Schwartz Arch Linux Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
