Re: Assignment to RO variable

[Chet Ramey]

On 8/15/23 9:57 PM, Wiley Young wrote:


 From within a stack of x3 functions called from a case within a for loop,
when trying to assign a value to a read-only variable, `printf` and `read`
both fail with exit codes of 1, and the functions, `case` and `for`
commands all complete.  When trying effectively the same thing with a
simple assignment syntax, `x=z`, when the assignment fails, the functions
return, `case` fails to complete and `for` returns an exit code of 1.


Assigning to a readonly variable using an assignment statement is a
variable assignment error, which causes non-interactive shells to exit
(POSIX mode) or return to the top level to read another command (default
mode). Interactive shells abandon execution of the command and return
to the top level.

https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_09_01 
says


"If any of the variable assignments attempt to assign a value to a variable 
for which the readonly attribute is set in the current shell environment 
(regardless of whether the assignment is made in that environment), a 
variable assignment error shall occur. See Consequences of Shell Errors for 
the consequences of these errors."


Builtins that assign variables as a side effect of execution (e.g., read,
printf, getopts) do not treat attempts to assign to readonly variables as
variable assignment errors; they simply cause the builtin to fail and
return a non-zero status.

--
``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: Assignment to RO variable

[Martin D Kealey]

On Wed, 16 Aug 2023 at 14:24, Dennis Williamson 
wrote:

> Your use of colon as a comment character is confusing.
>

Colon is only confusing if one mistakes it for a comment.
Colon is not a comment, it's a command, and therefore included in xtrace
output.

Of course, the real problem is that colon's own exit status is always zero,
and that will prevent the exit status of the preceding command from
propagating out of a case/esac block or out of a function.

-Martin

Re: Assignment to RO variable

[Greg Wooledge]

On Tue, Aug 15, 2023 at 11:24:31PM -0500, Dennis Williamson wrote:
> Your use of colon as a comment character is confusing.

They're running with set -x, so presumably they used those : commands
to mark the set -x output with various labels.  Which seems nominally
clever, except they didn't *show* us the output.  Also, the example
is way more complicated than it needs to be, to the point where I
gave up trying to suss out what part of it they thought was behaving
incorrectly.

Compare with this example:


unicorn:~$ cat foo
#!/bin/bash

f() {
local x=in_function_f
echo "still in f"
}

readonly x=global
f
unicorn:~$ ./foo
./foo: line 4: local: x: readonly variable
still in f


As you stated, a variable that has been declared readonly at the global
scope is also considered readonly at every other scope.  This is the
intended behavior.

After the failed local variable assignment, the function continues
execution.  This is also the intended behavior, as this example does
not use any of the set -e variants.