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

[Zachary Santer]

On Fri, Feb 23, 2024 at 7:40 AM Greg Wooledge <greg@wooledge.org> wrote:

> On Fri, Feb 23, 2024 at 07:23:49AM -0500, Zachary Santer wrote:
> > 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.
>
> Assignments preceding a simple command create environment variables
> for the duration of the simple command.  Array variables cannot be
> exported into the environment, so they're already disqualified from
> consideration here.
>

There's a preprocessor directive to allow Bash to export array variables
though, right? That directive is off by default, so don't expect to be able
to do it in a script, but it's probably best that any changes made to Bash
still make sense if that directive were turned on. Unless that directive
gets removed at some point. Having a new way to unset a variable that will
only work in the case of preceding a simple command would be kind of weird.


> With all that said, I don't plan to implement this, nor would I expect
> Chet to do so if it's a pain.  I could see a *small* benefit to having
> this syntactic feature available, but not enough to demand it.  Existing
> scripts that use commands like
>
>     (unset DISPLAY; xsomething)
>
> will continue to work, and provide the same results that the proposed
> feature would provide.  Such commands are pretty rare in my experience.
>

Kind of with you there, honestly. Didn't think of using a subshell to
accomplish this earlier.