Stephane Chazelas via austin-group-l at The Open Group wrote in
<dg7uljqxoswqvikrodohe274t2r32bwhcwjbcfs5qiaj7oaon2@dbo5mn43lynf>:
|2024-11-04 23:57:54 +0100, Steffen Nurpmeso via austin-group-l at The \
|Open Group:
|[...]
|> If you mean set(1) getting an option to explicitly control
|> *which* local there is, then that is cool .. and maybe the best of
|> all options. Indeed. Also because people then can do things like
|>
|> (set -o tabcomplete) >/dev/null 2>&1 && set -o tabcomplete
|[...]
|
|As mentioned earlier in this thread, bash has already introduced
|the localvar_inherit and localvar_unset options (though in the
|set managed by shopt, not the one managed by set -o).
This must have escaped me.
...
(It follows an extensive overview of what happens in shells)
...
|POSIX could specify the localvar_inherit and localvar_unset
|options, but for the latter that would likely mean that the
|behaviour when localvar_unset is not on would have to be left
|unspecified because:
|
|1. It differs between mksh/yash and bash
|2. IMO, it's an undesirable behaviour¹ that would not be worth
| implementing let alone specifying, we'd only be introducing
| that option to account for existing implementation behaviour
| which they're not willing to change.
|
|For localvar_inherit, it's not perfect either because there
|are some shells which are in the don't-inherit category in that
|they don't inherit the value but either inherit the attributes,
|or don't mask the variable marked for export in the parent
|scope.
|
|e.g:
|
|$ mksh -c 'export a=1; f() { local a=2; printenv a; }; f'
|1
|$ yash -c 'export a=1; f() { local a=2; printenv a; }; f'
|1
|$ bash -c 'export a=1; f() { local a=2; printenv a; }; f'
|2
|$ bash -O localvar_inherit -c 'export a=1; f() { local a=2; printenv \
|a; }; f'
|2
|$ bash +O localvar_inherit -c 'export a=1; f() { local a=2; printenv \
|a; }; f'
|2
|$ dash -c 'export a=1; f() { local a=2; printenv a; }; f'
|2
|$ bosh -c 'export a=1; f() { local a=2; printenv a; }; f'
|2
|$ ksh -c 'export a=1; function f { typeset a=2; printenv a; }; f'
|$ zsh -c 'export a=1; f() { local a=2; printenv a; }; f'
|$ netbsd-sh -c 'export a=1; f() { local -N a=2; printenv a; }; f'
|$
|
|(I don't have access to a ksh88 to test that on ATM)
|
|To me, ksh/zsh (and NetBSD sh with -N) are the ones which truely
|don't inherit. dash (like NetBSD's sh (without -N) on which it
|is based) inherits so it's expected there.
If POSIX is to add local then it seems it will not work out except
with either something completely new, or by following a narrow
path with undefined behaviours left and right.
Maybe shell programmers can be given a hint via several different
possible option names to set(1) so they get a notion on what the
actual implementation does, depending on which setting can be
successfully enabled.
I agree with you regarding "truly don't inherit". For the MUA
i was desperate because of the costs of "doing it right". (It is
more expensive here though.)
|2024-11-04 23:54:20 +0100, Steffen Nurpmeso via austin-group-l at The \
|Open Group:
|[...]
|> I see however people jumping of joy they are enabled to write
|> "local --inherit" or "local --scope" or "local --reallylocal" or
|> so. Or even the self-describing "local -i" because long options
|> are not POSIX, and "local inherit" it cannot be either.
|
|That doesn't fill me with joy either but as mentioned earlier,
|there's already a precedent with NetBSD sh implementing local -N
|and local -I (-i, -u and -U are already taken in some shells) as
|a good will gesture to try and move things forward.
|
|And that means new syntax for all shells which means one where
|all implementers can agree on a behaviour (the one in NetBSD
|looks fine to me and AFAICT is in agreement with the rough
|specification I suggested previously).
Then future scripts can be written like so, elder scripts are all
off limits.
|--
|Stephane
|
|¹ I'd even go as far as saying that an unset that doesn't unset is a bug.
|
--End of <dg7uljqxoswqvikrodohe274t2r32bwhcwjbcfs5qiaj7oaon2@dbo5mn43lynf>
--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
|
|And in Fall, feel "The Dropbear Bard"s ball(s).
|
|The banded bear
|without a care,
|Banged on himself fore'er and e'er
|
|Farewell, dear collar bear
