Suggestion for nesting multiple parameter expansions as ${{param..}...}

[Kenneth Irving]

Not a bug, but a suggestion...  Given a file like '@var:try-duplicate-names
'
I have this code to extract the text between '@' and ':' into variable key:

   for file in "${files[@]}"; do
key="${file#@}"
key="${key%:*}"
readListFile "$key" "$file" ""
   done

An alternative syntax to do multiple expansions on a single parameter might
be:

key="${{file#@}%:*}"

Or, without using an intermediate variable:

   for file in "${files[@]}"; do
readListFile "${{file#@}%:*}" "$file" ""
   done

I think this proposed syntax might be easy to parse, and probably doesn't
conflict with existing valid bash syntax.  Other shells may take another
approach, e.g. I guess zsh allows nesting whole parameter expansion
sequences, like ${${file#@}%:*}, but I think with the proposed syntax it is
clearer to see what's going on.  In either case (this proposal or
zsh's syntax) the parameter name just has to appear once, vs one time for
each expansion in current bash; the repetition of parameter names has been
a source of bugs in some of my code in the past where multiple expansions
were needed on a single parameter.

For the record, I'm running this version of bash:

GNU bash, version 4.4.23(1)-release (x86_64-apple-darwin17.5.0)
installed using homebrew probably years ago on a MacOS laptop, where
the default bash is quite a bit older:

GNU bash, version 3.2.57(1)-release (x86_64-apple-darwin20)

Ken

-- 
Ken Irving

Re: Handling options with optional arguments with getopts

[Kenneth Irving]

On Fri, Aug 27, 2021 at 11:33 AM Lawrence Velázquez  wrote:
>
> On Fri, Aug 27, 2021, at 1:20 PM, nigelberlinguer wrote:
> > ‐‐‐ Original Message ‐‐‐
> > On Friday, August 27, 2021 4:02 PM, Robert Elz  wrote:
> > > XBD 12.2 guideline 7 is:
> > >
> > > Guideline 7: Option-arguments should not be optional.
> > >
> > > That is, if you want to be able to give an option arg, or not give one,
> > > those should be implemented as 2 separate options.
> >
> > It should be noted though, that the POSIX requirement by "Guideline 7"
> > is not guided by actual portability in the technical sense but by a
> > rule written in the POSIX standard.  Perhaps there should be an update
> > to POSIX on what is actually portable or not
>
> https://www.opengroup.org/austin/lists.html
>
> --
> vq
>

> I also wonder whether the "shift" command is used with `getopts`.  I see 
> people use
> the `shift` command when doing their own parsing; and when others use 
> `getopt`.

$  help shift
shift: shift [n]
Shift positional parameters.
Rename the positional parameters $N+1,$N+2 ... to $1,$2 ...  If N is
not given, it is assumed to be 1.
Exit Status:
Returns success unless N is negative or greater than $#.

 $  help set
set: set [-abefhkmnptuvxBCHP] [-o option-name] [--] [arg ...]
Set or unset values of shell options and positional parameters
Change the value of shell attributes and positional parameters, or
display the names and values of shell variables.
 ...



-- 
Ken Irving