All of lore.kernel.org
 help / color / mirror / Atom feed
From: Anthony PERARD <anthony@xenproject.org>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: "Marek Marczykowski-Górecki" <marmarek@invisiblethingslab.com>,
	Xen-devel <xen-devel@lists.xenproject.org>,
	"Stefano Stabellini" <sstabellini@kernel.org>,
	"Michal Orzel" <michal.orzel@amd.com>
Subject: Re: [PATCH 2/3] CI: Use bash arrays to simplfy dom0 rootfs construction
Date: Wed, 28 May 2025 11:45:19 +0200	[thread overview]
Message-ID: <aDbbL9cgz5ZqFV5O@l14> (raw)
In-Reply-To: <b5dfadcb-6f22-40bb-84a9-fcc48955c44c@citrix.com>

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@citrix.com>
> >>> ---
> >>> 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


  reply	other threads:[~2025-05-28  9:45 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-05-22 17:36 [PATCH 0/3] CI: Improve domU handling Andrew Cooper
2025-05-22 17:36 ` [PATCH 1/3] CI/qubes: Deduplicate the handling of ${dom0_check} Andrew Cooper
2025-05-27 13:41   ` Anthony PERARD
2025-05-28  0:18     ` Stefano Stabellini
2025-05-22 17:36 ` [PATCH 2/3] CI: Use bash arrays to simplfy dom0 rootfs construction Andrew Cooper
2025-05-27 14:01   ` Anthony PERARD
2025-05-27 15:19     ` Marek Marczykowski-Górecki
2025-05-27 15:24       ` Andrew Cooper
2025-05-28  9:45         ` Anthony PERARD [this message]
2025-05-28 12:12           ` Andrew Cooper
2025-05-28  0:19     ` Stefano Stabellini
2025-05-22 17:36 ` [PATCH 3/3] CI: Adjust how domU is packaged in dom0 Andrew Cooper
2025-05-27 13:55   ` Marek Marczykowski-Górecki
2025-05-27 15:57     ` Andrew Cooper
2025-05-28  0:30   ` Stefano Stabellini
2025-05-28  0:38     ` Andrew Cooper
2025-05-28  0:59       ` Stefano Stabellini

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aDbbL9cgz5ZqFV5O@l14 \
    --to=anthony@xenproject.org \
    --cc=andrew.cooper3@citrix.com \
    --cc=marmarek@invisiblethingslab.com \
    --cc=michal.orzel@amd.com \
    --cc=sstabellini@kernel.org \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.