David A. Wheeler via austin-group-l at The Open Group wrote in
<1d993726-07a4-41de-85f4-59e395129...@dwheeler.com>:
|
|
|> On Nov 3, 2024, at 1:40 PM, Christoph Anton Mitterer via austin-group-l \
|> at The Open Group <austin-group-l@opengroup.org> wrote:
|>
|> On Sun, 2024-11-03 at 18:34 +0000, Stephane Chazelas via austin-group-l
|> at The Open Group wrote:
|>> nothing I can think of sound really appealing.
|>
|> I found the idea with options to `local`, where only these option make
|> it truly portable intriguing.
|>
|> Portability aside, it might allow to exactly control what should
|> happen, like how the masking works of unset variables, etc..
|
|Using "local" also:
|* makes the final result more like existing practice. People *currently* \
|use
| the keyword "local" for local variables.
Yeah .. but *which* one?
|* Avoids the problem that someone might use another keyword for a command.
| E.g., there's probably someone out there with functions or commands \
| named "my" or "ours".
| However, it's widely expected that "local" is a shell built-in for \
| local variables.
| Adding an option for portability on an existing use of "local" is \
| easy to understand
| and doesn't risk interfering with anything else.
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
--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
