Re: How functions are defined
On Apr 27 2020, Dale R. Worley wrote: > So it seems the reserved rule is more accurately: > >Reserved words are words that have a special meaning to the >shell. The following words are recognized as reserved when >unquoted and either (1) where the first word of a simple command >could be (see SHELL GRAMMAR below), (2) the third word of a case, >for, or select command, the (3) first word of the body of a function >definition, or (4) after a semicolon or newline: > > IIUC there are two places where the documentation needs to be updated, > bash/doc/bash.1 and bash/doc/bashref.texi. But the above wording is a > lot more complex than I'd like. Does anyone have suggestions for a > clearer way to say this that is still accurate? > > ... Looking at this again, I think (1) and (3) can be replaced by "the > first word of a command (see SHELL GRAMMAR below)", which helps. Isn't (4) also a subset of (1)? 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: How functions are defined
Date:Mon, 27 Apr 2020 22:03:47 -0400
From:wor...@alum.mit.edu (Dale R. Worley)
Message-ID: <87pnbsfjss@hobgoblin.ariadne.com>
| While I was looking at the details of parsing function definitions, I
| tripped on something I should have noticed long ago. In the function
| definition
|
| function foo() {
| command
| }
I think this is your problem. The definition of a function is
really
name ( ) compound-command
and in the ksh/bash variant version
function name ( ) compound-command
There are no braces in the syntax (and I omitted redirections which are
not relevant here).
When looking for a "compound-command" we start out looking for the
first word of a command, and that's exactly where a reserved word
can be found.
Some shells actually permit
name ( ) command
instead where it is even clearer (but which gives rise to one small,
and mostly irrelevant, ambiguity - also not relevant here.)
Note that the text you quoted:
Reserved words are words that have a special meaning to the shell. The
following words are recognized as reserved when unquoted and either the
first word of a simple command ...
note that "first word" has nothing to do with lines, that the "name ()"
comes earlier doesn't mean that a command (or compound-command) doesn't
follow, and that thing starts with a "first word" (of itself).
kre
Local variable names clash with global read-only variable names.
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -march=x86-64 -mtune=generic -O2 -pipe -fno-plt
-DDEFAULT_PATH_VALUE='/usr/local/sbin:/usr/local/bin:/usr/bin'
-DSTANDARD_UTILS_PATH='/usr/bin' -DSYS_BASHRC='/etc/bash.bashrc'
-DSYS_BASH_LOGOUT='/etc/bash.bash_logout' -DNON_INTERACTIVE_LOGIN_SHELLS
-Wno-parentheses -Wno-format-security
uname output: Linux charon 5.6.4-arch1-1-user-regd #1 SMP PREEMPT Fri, 17 Apr
2020 12:06:27 + x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu
Bash Version: 5.0
Patch Level: 16
Release Status: release
Description:
Global and local variable namespaces are distinct in the most common case:
f() { local x=a; }
x=b
f
echo "$x" # still 'b', as expected
However, this^^^ example stops working when $x is declared read-only:
Repeat-By:
f() { local x=a; }
declare -r x
f # bash: local: x: readonly variable
This^^^ should not fail; it hinders reusability of shell functions and makes
them context-dependent.
Re: Local variable names clash with global read-only variable names.
On Tue, Apr 28, 2020 at 08:14:28PM +0200, andrej--- via Bug reports for the GNU
Bourne Again SHell wrote:
> f() { local x=a; }
> declare -r x
> f # bash: local: x: readonly variable
>
> This^^^ should not fail; it hinders reusability of shell functions and makes
> them context-dependent.
The purpose of 'readonly' as a variable attribute is to supplement a
restricted shell environment. If a variable is set readonly, it's because
the system administrator, or whoever set up the enviroment, demands that
this variable NOT be changed by the end user.
If the end user were able to change it simply by declaring it as local
inside a function, breaking the restricted shell would be too easy.
(The fact that restricted shells are a joke doesn't change this stance.)
