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.