Re: feature todo .. be able to unset vars at assignment stage , without unset util , for coding language fair extendment

[Zachary Santer]

On Thu, Feb 22, 2024 at 10:58 PM Greg Wooledge <greg@wooledge.org> wrote:

> On Thu, Feb 22, 2024 at 10:52:59PM -0500, Zachary Santer wrote:
> >
> > Maybe something like var=${<>} could unset var. Something between the
> curly
> > braces that would just be a syntax error otherwise.
>
> ${} is nicely erroneous, currently, as is ${~}.
>

This would look inconsistent with how the rest of variable assignments work
when you're trying to unset an entire array, though.

var='whatever' sets var[0] if var is already an indexed or
associative array, so expecting var=${<>} or var=${~} to unset the entire
array doesn't work. var[@]='whatever' will set the literal index '@' in an
associative array, so var[@]=${~} is out. Same applies for *.

The parser can tell ${var[@]} and ${var['@']} apart, though. That would
leave you with syntax that doesn't look like an assignment at all.
${~var[@]} to unset the entire array. ${~var['@']} to unset the element
with index '@'.

Given the use case of unsetting a variable in a command's environment,
you're still going to end up with something that doesn't look consistent:
PATH='/usr/bin' ${~BASH_ENV} ./script
to set PATH like this and unset BASH_ENV in ./script's environment.

Given that, I might expect
${~var}
to unset var on its own without having to follow :.

Honestly, it's probably better off without the dollar sign even, since it's
not going to look like an assignment, and it isn't an expansion. But {~var}
isn't a syntax error, it's just a regular word, so who knows if somebody
already has it in a script for some reason?

I imagine this feature would now require more changes to the parser, too.
Is it worth it? Anybody got better ideas?