Re: [PATCH 2/3] CI: Use bash arrays to simplfy dom0 rootfs construction

[Anthony PERARD <anthony@xxxxxxxxxxxxxx>]

On Tue, May 27, 2025 at 04:24:57PM +0100, Andrew Cooper wrote:
> On 27/05/2025 4:19 pm, Marek Marczykowski-Górecki wrote:
> > On Tue, May 27, 2025 at 04:01:34PM +0200, Anthony PERARD wrote:
> >> On Thu, May 22, 2025 at 06:36:39PM +0100, Andrew Cooper wrote:
> >>> For Qubes, this requires switching from sh to bash.
> >>>
> >>> This reduces the number of times the target filename needs to be written 
> >>> to 1.
> >>>
> >>> Expand the comment to explain the concatination constraints.
> >> Isn't the correct spelling "concatenation"? Same for the two comments.
> >>
> >>> No functional change.
> >>>
> >>> Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
> >>> ---
> >>> I would like to find a slightly nicer way of conditional parts, but 
> >>> nothing
> >>> comes to mind.
> >> Well, one way I can think of is having a new variable which can carry
> >> the rootfs part associated with a particular test, then that variable
> >> can be updated at the time we configure for that test. Something like:
> >>
> >> # init
> >> declare -a append_rootfs_part
> >> # or append_rootfs_part=() is probably fine too.
> >>
> >> case $test in
> >>   argo)
> >>     append_rootfs_part+=(argo.cpio.gz)
> >>     # ... other test configuration
> >>     ;;
> >> esac
> >>
> >> # Dom0 rootfs
> >> parts=(
> >>     rootfs.cpio.gz
> >>     xen-tools.cpio.gz
> >>     "${append_rootfs_part[@]}"
> >> )
> >>
> >> And that should works fine, even if there isn't any extra rootfs part.
> > That would work for compressed parts, but not for uncompressed - which
> > need to come before all compressed. But maybe there could be two arrays
> > - one for uncompressed and another for compressed? Then, each could be
> > extended anywhere, without messing the order.

You could use "${append_rootfs_part:#*.gz}" and
"${(M)append_rootfs_part:#*.gz}" to grab the uncompressed part then the
compressed part... on zsh :-). But something similar could be codded in
bash. But I guess two variables will be more acceptable.

> Hmm, two might work, but they surely need to not be quoted when forming
> parts=(), or having multiple entries will go wrong on the eventual cat
> command line.

The double quote are needed! Well not really because it's very unlikely
that there's going to be blanked characters in paths to parts.

Maybe this will help understand how "${var[@]}" is expended into
multiple arguments:

# Testing with just for loop, also show the difference between
#  "${v[@]}" and "${v[*]}":

$ parts=(one two)
$ for i in "${parts[@]}"; do echo "- $i"; done
- one
- two
$ for i in "${parts[*]}"; do echo "- $i"; done
- one two
$ extra=("first extra" "second extra")
$ for i in "${extra[@]}"; do echo "- $i"; done
- first extra
- second extra
$ parts=(one "${extra[@]}" two)
$ for i in "${parts[@]}"; do echo "- $i"; done
- one
- first extra
- second extra
- two

# And now with function

$ print_array(){ for i in "$@"; do echo "- $i"; done; }
$ print_array "${parts[@]}"
- one
- first extra
- second extra
- two
$ print_array ${parts[@]}
- one
- first
- extra
- second
- extra
- two

Cheers,

-- 
Anthony PERARD