On Wednesday 03 April 2013 09:34:18 Chet Ramey wrote: > A variable is declared readonly for a reason, and, since readonly variables > may not be assigned to, I don't believe you should be able to override a > readonly variable by declaring it local to a function. I did, however > reluctantly, allow a way to do this by permitting a function writer to > override local readonly variables (given bash's dynamic scoping) or to > override global readonly variables when several levels down in the call > stack.
sounds like the fundamental limitation is that the person writing the code
can't declare their intentions. after your compromise, they now can. if you
follow the convention of putting all code into a main() func (rather than
executing code in global scope), you can do:
#!/bin/bash
... declare all your funcs ...
main() {
declare -gr VAR=value # i really want this to stay read-only
declare -r FOO=value # i'm ok with people overriding this in funcs
...
}
main "$@"; exit
having this flexibility just came up in the Gentoo world and i'm glad i saw
this thread as now we have a technical solution :). we have some vars we want
to be read-only and not overridable, but we have a few we want to default to
read-only but allow people to localize.
> The current behavior is a compromise. Compromises always come back to
> bite you because the inconsistencies that result are more trouble than
> the flexibility they offer is worth.
would it be possible to enable a mode where you had to explicitly `declare +r`
the var ? being able to "simply" do `local FOO` allows accidental overriding
in sub funcs where the writer might not have even realized they were
clobbering something possibly important.
i'm not interested in debating the "you should be familiar with the code base"
as that's not being realistic. large code bases in the open source world, by
their nature, accept drive by commits and accidents happen.
-mike
signature.asc
Description: This is a digitally signed message part.
