From: Johannes Schindelin Date: Thu, 24 Sep 2026 19:55:53 GMT Subject: Re: [PATCH 3/4] ci(gitlab,windows): fix Rust setup for GitLab's MinGW build Message-ID: <1c829af9-1923-a6ff-78a1-b738cc6bf5a6@gmx.de> In-Reply-To: Hi Patrick, On Thu, 24 Sep 2026, Patrick Steinhardt wrote: > On Sat, Sep 19, 2026 at 12:12:12PM +0000, Johannes Schindelin via GitGitGadget wrote: > > diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml > > index cd6fd4a504..3f24835500 100644 > > --- a/.gitlab-ci.yml > > +++ b/.gitlab-ci.yml > > @@ -133,8 +133,11 @@ build:mingw64: > > before_script: > > - *windows_before_script > > - ./ci/install-sdk.ps1 -directory "git-sdk" > > + - ./ci/install-dependencies.ps1 -Mingw > > I wonder whether it would now make sense to also hoist "install-sdk.ps1" > into "install-dependencies.ps1" now. Honestly, I wouldn't. It is conceptually a different thing, the SDK brings a ready-configured environment (which _partially_ ships dependencies, that's right, but it's a Venn diagram, not a strict super set relationship). > > script: > > - - git-sdk/usr/bin/bash.exe -l -c 'ci/make-test-artifacts.sh artifacts' > > + # The minimal SDK's profile resets PATH. > > + - git-sdk/usr/bin/bash.exe -l -c > > + 'PATH=$PATH:/c/Rust/bin ci/make-test-artifacts.sh artifacts' > > Are we sure that PATH cannot ever contain spaces or should we rather > quote here? Ah, quoting in shell, what a wonderfully magical world. While you would be correct that passing an unquoted `$PATH` as an _argument_ would cause unwanted misinterpretation as multiple arguments instead of a single one, _assigning variables_ is a completely different issue. Observe: $ x="Patrick Steinhardt"; x=$x=hello env | grep ^x= x=Patrick Steinhardt=hello Wha...? It did _not_ split the $x at whitespace? No. In what must have occurred as quite logical to the inventors of the Unix shell syntax, interpolating unquoted variables in assignments does *not* split at whitespace, unlike in other instances where unquoted variables are very much split at whitespace. Ciao, Johannes