Christoph Anton Mitterer wrote, on 25 Apr 2022:
>
> On Fri, 2022-04-22 at 15:36 +0100, Geoff Clare via austin-group-l at
> The Open Group wrote:
> > > However some shells may e.g. wish to provide such invalidly named
> > > env vars
> > > in a special shell var (like an associative array)... so that
> > > should
> > > perhaps be allowed?
> >
> > Yes, that's allowed (see below), but to be clear - such things are
> > not "special shell variables". They cannot be shell variables of any
> > kind because shell variables always have valid names.
>
> With "special shell variable" I meant something like the variable
> (associative array) BASH_INVALIDLY_NAME_ENV_VARS (not that it would
> really exist in current bash versions).
> So that would still have a valid name itself, but contain those env
> vars, with invalid names.
See below.
> > > > ... for character substring processing.
> > >
> > > May I suggest to rather directly write something like:
> > > "The following four varieties of parameter expansion provide for
> > > substring
> > > processing, with each of them requiring the value to be a character
> > > string."
> > >
> > > Especially the "substring" makes it IMO a tiny bit vague... like
> > > in:
> > > foo="${binaryString}."
> > > cmdSubstWithTrailingNL=${foo%.}
> > >
> > > One could claim: "well,... the '.' is a substring of $foo... and
> > > only that
> > > is processed as character and matched... so fine"
> > >
> > > Further, this basically assume the current proposal of
> > > https://www.austingroupbugs.net/view.php?id=1562 ... i.e. that
> > > pattern
> > > matching notation would always be on character strings.
> > > However, on the mailing list, Harald van Dijk offered to look more
> > > deeply
> > > into that matter, ... So may I kindly request that you defer voting
> > > on this
> > > particular part of the above changes, until Harald had a chance to
> > > do so?
> >
> > Agreed.
>
> If your "agreed" goes also for the first part of my reply... (and not
> just the deferring) then it would perhaps make sense to change still
> change the proposal now (accordingly) and just don't vote on it.
>
> Otherwise I guess the first suggestion (about the vagueness of
> "substring") would be easily forgotten.
I was agreeing to the deferral. I don't see a problem with this use
of "substring", but in any case there is no point working on minutiae
of the wording until the bigger question has been settled.
> > > > However, the shell may initialize parameters that do not have
> > > > valid names
> > > from such environment variables.
> > >
> > > What's that intended for? To allow positional/special parameters to
> > > be
> > > initialised from the environment variable?
> >
> > This is what you wanted above when you said "some shells may e.g.
> > wish
> > to provide such invalidly named env vars in a special shell var (like
> > an associative array)". As I pointed out there, such things are not
> > any kind of shell variable, which is why I called them parameters
> > here.
>
> Well but then the wording of your sentence seems wrong or at least
> confusing to me:
>
> > However, the shell may initialize parameters that do not have valid
> > names from such environment variables.
>
> "initialize parameters that do not have valid names"
>
> => how could it initialise a parameter that does not have a valid
> name? That's forbidden?!
> 2.5 Parameters and Variables
> "A parameter can be denoted by a name, a number, or one of the
> special characters listed in Special Parameters."
>
> So either it's a (valid) name (and would be e.g.
> BASH_INVALIDLY_NAME_ENV_VARS, and I guess it doesn't matter here
> whether one would consider that a variable or parameter), or it's a
> digit (and thus a positional param... and thus this cannot be used for
> that purpose) or a special char, which would require such shells to use
> such special char for that purpose.
No. You are reading too much into that statement from 2.5. It says
a parameter *can* be denoted by a name, a number, or a special
character. It does not say that a parameter *can't* be denoted by
other things as well.
> For the latter... does it really make sense to encourage them doing
> this?
The special characters listed in the referenced section all have
strictly defined purposes. They can't be used for something else.
> Wouldn't it rather make sense to just allow them something like
> BASH_INVALIDLY_NAME_ENV_VARS?
I think my wording allows that. The array itself is an extension and
thus not affected by what the standard says here. However, each
element of the array would be considered to be a parameter (denoted
by "name[index]"), and thus allowed to be initialised.
--
Geoff Clare <[email protected]>
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
