Re: Bash parameter transforamtion on empty array triggers unset variable.
On 8/11/20 11:45 AM, Andrew Neff wrote:
> Ah, I see the confusion.
>
> The issue you pointed out, "@Q breaks set -o nounset" refers to quote
> parameter expansion, as does the line in CHANGES-5.1, 1.q, which makes
> sense to call this a bug that was allowed in bash 4.4 and 5.0.
Not quite. The report revealed that none of the parameter transformations
obeyed `set -u'. The fix was to make that happen, so that parameter
transformations were aligned with the other word expansions.
> I should have specified, the focus of this issue is the "@a" expansion.
Sure, you want an exception.
> It
> makes sense that @Q/E/P/A expansion should not work on unset variables with
> nounset enabled. However, @a is uniquely different, in that it does not
> have to do with the value of the variable, but rather the variable type.
This is why it works on unset variables when `set -u' isn't enabled. The
question is whether that makes it special enough to be an exception.
> Here are 3 specific details I would like to address:
>
> 1. @a expansion should work on unset variables with "set -u" in bash 5.1.
> It seems like the correct thing to do. Only @a expansion. This has been a
> very useful feature in bash 4.4 and 5.0.
OK, you found it useful in something you wanted to do. You're restating the
proposition.
>
> 2. With "set -u", the following works in bash 4.4 or newer (and makes sense
> that it works): (set -eu; x=(); echo "${x[@]}")
> Here x is not unset, it is set to an empty array. This expansion make sense
> with nounset turned on because x is not unset, it is set to ()
That's not why. The variable is indeed unset. The reason it doesn't fail
is because there's a special POSIX carveout for $@ with no positional
parameters and I extended it to ${var[@]}. The expansions of $@ and ${A[@]}
parallel each other in just about every other way, so it made sense.
> 3. The same as #2, but for associative arrays
> Works: (set -eu; declare -A x=(); echo "${x[@]}")
The same carveout for ${A[@]}.
So I guess the question is whether or not @A and @a are exceptional enough.
--
``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/
Dashes in function names: Undocumented?
I put a bug report into an emacs group because the bash syntax highlighter failed to recognize functions whose names have dashes in them. The maintainer came back with this: I can reproduce this behaviour, but is it really a bug? Aren't the names with '-' invalid? The Bash Reference Manual says: name A word consisting solely of letters, numbers, and underscores, and beginning with a letter or underscore. Names are used as shell variable and function names. Also referred to as an identifier. https://www.gnu.org/savannah-checkouts/gnu/bash/manual/bash.html I looked at the manual and I didn't see positive or negative acknowledgement that dashes can be used in function names. But it does work. Update to manual? name A word consisting solely of letters, numbers, and underscores, and beginning with a letter or underscore. Names are used as shell variables. Also referred to as an identifier. function name A word consisting solely of letters, numbers, underscores, dashes, and beginning with a letter or underscore. Function names are used to label shell functions. -- Matthew O. Persico
Re: Dashes in function names: Undocumented?
On 8/12/20 10:51 AM, Matthew Persico wrote: > I put a bug report into an emacs group because the bash syntax highlighter > failed to recognize functions whose names have dashes in them. > > The maintainer came back with this: > > I can reproduce this behaviour, but is it really a bug? Aren't the > names with '-' invalid? > The Bash Reference Manual says: > name > A word consisting solely of letters, numbers, and underscores, and > beginning with a letter or underscore. Names are used as shell > variable and function names. Also referred to as an identifier. > https://www.gnu.org/savannah-checkouts/gnu/bash/manual/bash.html > > I looked at the manual and I didn't see positive or negative > acknowledgement that dashes can be used in function names. But it does work. > > Update to manual? The bash-20191127 snapshot updated the manpage documentation for a function definition (to align with reality). It is now defined as: function fname [()] compound-command [redirection] and includes the description: When in posix mode, fname must be a valid shell name and may not be the name of one of the POSIX special builtins. In default mode, a function name can be any unquoted shell word that does not contain $. For context: word - A sequence of characters considered as a single unit by the shell. Also known as a token. name - A word consisting only of alphanumeric characters and underscores, and beginning with an alphabetic character or an underscore. Also referred to as an identifier. > name > A word consisting solely of letters, numbers, and underscores, and > beginning with a letter or underscore. Names are used as shell > variables. Also referred to as an identifier. > > function name > A word consisting solely of letters, numbers, underscores, dashes, and > beginning with a letter or underscore. Function names are used to label > shell > functions. > -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [PATCH] fc: trim range instead of erroring out
On 8/11/20 11:59 AM, Martijn Dekker wrote: > This is different from every other shell, and also looks like it's contrary > to the POSIX spec: > https://pubs.opengroup.org/onlinepubs/9699919799/utilities/fc.html#tag_20_44_05 > > | When a range of commands is used, it shall not be an error to specify > | first or last values that are not in the history list; fc shall > | substitute the value representing the oldest or newest command in the > | list, as appropriate. For example, if there are only ten commands in > | the history list, numbered 1 to 10: > | > | fc -l > | fc 1 99 > | > | shall list and edit, respectively, all ten commands. What's your opinion about what the `as appropriate' means? An out-of-range `first' gets substituted with the first command in the history, and an out- of-range `last' gets the last history entry? Bash does one thing, your patch does another, but neither one does that. -- ``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: Dashes in function names: Undocumented?
On Wed, Aug 12, 2020 at 11:06 AM Eli Schwartz wrote: > On 8/12/20 10:51 AM, Matthew Persico wrote: > > I put a bug report into an emacs group because the bash syntax > highlighter > > failed to recognize functions whose names have dashes in them. > > > > The maintainer came back with this: > > > > I can reproduce this behaviour, but is it really a bug? Aren't the > > names with '-' invalid? > > The Bash Reference Manual says: > > name > > A word consisting solely of letters, numbers, and underscores, and > > beginning with a letter or underscore. Names are used as shell > > variable and function names. Also referred to as an identifier. > > https://www.gnu.org/savannah-checkouts/gnu/bash/manual/bash.html > > > > I looked at the manual and I didn't see positive or negative > > acknowledgement that dashes can be used in function names. But it does > work. > > > > Update to manual? > > The bash-20191127 snapshot updated the manpage documentation for a > function definition (to align with reality). It is now defined as: > > function fname [()] compound-command [redirection] > > and includes the description: > > When in posix mode, fname must be a valid shell name and may not be the > name of one of the POSIX special builtins. In default mode, a function > name can be any unquoted shell word that does not contain $. > > For context: > > word - A sequence of characters considered as a single unit by the > shell. Also known as a token. > > name - A word consisting only of alphanumeric characters and > underscores, and beginning with an alphabetic character or an > underscore. Also referred to as an identifier. > > > > name > > A word consisting solely of letters, numbers, and underscores, and > > beginning with a letter or underscore. Names are used as shell > > variables. Also referred to as an identifier. > > > > function name > > A word consisting solely of letters, numbers, underscores, dashes, and > > beginning with a letter or underscore. Function names are used to label > > shell > > functions. > > > > > -- > Eli Schwartz > Bug Wrangler and Trusted User > > Thanks. I will take your word for it, as I cannot seem to find that text at https://www.gnu.org/savannah-checkouts/gnu/bash/manual/bash.html, unless that is not the canonical location for the manual. -- Matthew O. Persico
Re: Dashes in function names: Undocumented?
On 8/12/20 11:51 AM, Matthew Persico wrote: > Thanks. I will take your word for it, as I cannot seem to find that text at > https://www.gnu.org/savannah-checkouts/gnu/bash/manual/bash.html, unless > that is not the canonical location for the manual. The canonical location is surely the source code: https://git.savannah.gnu.org/cgit/bash.git/commit/?h=devel&id=091c6bc481bd2b405e39b6ad5967eb4fa2aab597 The link you're using claims to have been last updated on 12 May 2019, and I definitely would not rely on it being updated with every commit. You could get the html doc as a plaintext file from https://git.savannah.gnu.org/cgit/bash.git/plain/doc/bash.html?h=devel and then open it in an HTML viewer (opening the link in a browser does not work on its own because it is Content-Type: text/plain;) -- Eli Schwartz Arch Linux Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: Dashes in function names: Undocumented?
On 8/12/20 12:01 PM, Eli Schwartz wrote: > On 8/12/20 11:51 AM, Matthew Persico wrote: >> Thanks. I will take your word for it, as I cannot seem to find that text at >> https://www.gnu.org/savannah-checkouts/gnu/bash/manual/bash.html, unless >> that is not the canonical location for the manual. > > The canonical location is surely the source code: > https://git.savannah.gnu.org/cgit/bash.git/commit/?h=devel&id=091c6bc481bd2b405e39b6ad5967eb4fa2aab597 > > The link you're using claims to have been last updated on 12 May 2019, > and I definitely would not rely on it being updated with every commit. The manual on savannah describes the current major release, as does the manual on www.gnu.org. -- ``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/
