bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: feature suggestion: ability to expand a set of elements of an array


From: Zachary Santer
Subject: Re: feature suggestion: ability to expand a set of elements of an array or characters of a scalar, given their indices
Date: Fri, 28 Jun 2024 17:29:30 -0400

On Fri, Jun 28, 2024 at 9:11 AM Greg Wooledge <greg@wooledge.org> wrote:
>
> I'm still wondering when you'd ever use this in a shell script.

In my case, I've got a couple of things:

(1)
One script has an array of names for named pipes. It might only need
two of the six for a given invocation, so why create all six every
time you run it? It fills an array of names of only the named pipes it
will need, then it expands that in a call to mkfifo. A common set of
readonly integer variables, serving the same purpose as an enum, is
used to index into this array and related arrays containing fds and
pids. An array of necessary fd indices is being created at the same
time as the array of necessary named pipes. However, there's only one
index in that array for each pair of fds that will be exec'd, so I'd
just be replacing an array of necessary named pipe names with an array
of necessary named piped indices in this case. Not a huge improvement.
(Yes, this is the same script that got me interested in having the
coproc keyword more fully implemented.)

( 2 )
A script that I've written more recently generates some arrays
describing everything it needs to do before it starts making updates.
This allows the script to catch a lot of error conditions before
making any changes, instead of potentially leaving the user in a
partially-updated state. When the script then iterates through indices
of these arrays, it will need to reference elements at earlier indices
at a later point. This may be necessary multiple times. This is
handled when generating the arrays by listing the indices of earlier
elements as whitespace-delimited integers in an array element for each
later index you'll be at when this needs to happen.

So, right now, the array I need when I get there is generated like so:
local -a A=()
local -i j
for j in ${B[i]}; do
  A+=( "${C[j]#"${C[i]}/"}" )
done

It's much more natural in this script to call commands with arguments
"${A[@]}" than it is to call those commands multiple times.

Admittedly, in my case, the proposed syntax would leave me doing
local -a A=( "${C[@]( ${B[i]} )}" )
A=( "${A[@]#"${C[i]}/"}" )
which might not be a marked improvement.

If I didn't need that remove matching prefix pattern parameter
expansion, it might've been natural to call the following commands
like
command -- "${C[@]( ${B[i]} )}"

And, yes, I am trying to do some complicated stuff in bash in the most
reasonable way I can find. If you want to act on the output from
external commands, it seems like the only game in town, and running
external commands in general is much more natural in bash than
elsewhere.

Hate to think I'm the only guy here doing interesting stuff like this.

> The amount of work it would take to support this new syntax seems like it
> would exceed the value it adds to the quite rare script that would use it.

I wanted to know if this would be valuable to others. If it's not, then fine.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]