Rust for Linux List
 help / color / mirror / Atom feed
From: "Onur Özkan" <work@onurozkan.dev>
To: Miguel Ojeda <ojeda@kernel.org>
Cc: "Nathan Chancellor" <nathan@kernel.org>,
	"Nicolas Schier" <nsc@kernel.org>,
	linux-kbuild@vger.kernel.org, "Boqun Feng" <boqun@kernel.org>,
	"Gary Guo" <gary@garyguo.net>,
	"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
	"Benno Lossin" <lossin@kernel.org>,
	"Andreas Hindborg" <a.hindborg@kernel.org>,
	"Alice Ryhl" <aliceryhl@google.com>,
	"Trevor Gross" <tmgross@umich.edu>,
	"Danilo Krummrich" <dakr@kernel.org>,
	"Daniel Almeida" <daniel.almeida@collabora.com>,
	"Tamir Duberstein" <tamird@kernel.org>,
	"Alexandre Courbot" <acourbot@nvidia.com>,
	rust-for-linux@vger.kernel.org, "Onur Özkan" <work@onurozkan.dev>
Subject: Re: [PATCH] rust: rust_is_available: support testing with `bash` as `/bin/sh`
Date: Thu, 23 Jul 2026 16:42:05 +0300	[thread overview]
Message-ID: <20260723134208.55300-1-work@onurozkan.dev> (raw)
In-Reply-To: <20260719130723.162899-1-ojeda@kernel.org>

On Sun, 19 Jul 2026 15:07:23 +0200
Miguel Ojeda <ojeda@kernel.org> wrote:

> `command -v` behaves differently on `dash` vs. `bash` when faced with
> a file without the execute bit.
> 
> Thus, for the non-executable `rustc` and `bindgen` tests, support both
> possible outputs that the script currently gives.
> 
> This makes the test script clean on distributions like Fedora.
> 
> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
> ---
> Independently, we could add a custom check for the non-exec case in the
> actual shell script, but back then it was decided with Kbuild to avoid
> overcomplicating it for rare cases (which anyway give an error).
> 
>  scripts/rust_is_available_test.py | 14 ++++++++++++--
>  1 file changed, 12 insertions(+), 2 deletions(-)
> 
> diff --git a/scripts/rust_is_available_test.py b/scripts/rust_is_available_test.py
> index d6d54b7ea42a..752c59d5f55f 100755
> --- a/scripts/rust_is_available_test.py
> +++ b/scripts/rust_is_available_test.py
> @@ -177,7 +177,12 @@ else:
> 
>      def test_rustc_nonexecutable(self):
>          result = self.run_script(self.Expected.FAILURE, { "RUSTC": self.nonexecutable })
> -        self.assertIn(f"Running '{self.nonexecutable}' to check the Rust compiler version failed with", result.stderr)
> +        self.assertTrue(
> +            # `dash`.
> +            f"Running '{self.nonexecutable}' to check the Rust compiler version failed with" in result.stderr or
> +            # `bash`.
> +            f"Rust compiler '{self.nonexecutable}' could not be found." in result.stderr
> +        )
> 
>      def test_rustc_unexpected_binary(self):
>          result = self.run_script(self.Expected.FAILURE, { "RUSTC": self.unexpected_binary })
> @@ -205,7 +210,12 @@ else:
> 
>      def test_bindgen_nonexecutable(self):
>          result = self.run_script(self.Expected.FAILURE, { "BINDGEN": self.nonexecutable })
> -        self.assertIn(f"Running '{self.nonexecutable}' to check the Rust bindings generator version failed with", result.stderr)
> +        self.assertTrue(
> +            # `dash`.
> +            f"Running '{self.nonexecutable}' to check the Rust bindings generator version failed with" in result.stderr or
> +            # `bash`.
> +            f"Rust bindings generator '{self.nonexecutable}' could not be found." in result.stderr
> +        )
> 
>      def test_bindgen_unexpected_binary(self):
>          result = self.run_script(self.Expected.FAILURE, { "BINDGEN": self.unexpected_binary })
> 
> base-commit: 880c43b185ca52239e75bc546cc4f4d9154d0fed
> --
> 2.55.0

Nit: You can add some useful failure message, something like "$binary could not
found in the system". The default failure message for assertTrue is something
like "False is not True", which is not helpful. But the failed lines will also
be printed so it's not entirely unclear as well.

With/without that:

Reviewed-by: Onur Özkan <work@onurozkan.dev>

      reply	other threads:[~2026-07-23 13:42 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-19 13:07 [PATCH] rust: rust_is_available: support testing with `bash` as `/bin/sh` Miguel Ojeda
2026-07-23 13:42 ` Onur Özkan [this message]

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=20260723134208.55300-1-work@onurozkan.dev \
    --to=work@onurozkan.dev \
    --cc=a.hindborg@kernel.org \
    --cc=acourbot@nvidia.com \
    --cc=aliceryhl@google.com \
    --cc=bjorn3_gh@protonmail.com \
    --cc=boqun@kernel.org \
    --cc=dakr@kernel.org \
    --cc=daniel.almeida@collabora.com \
    --cc=gary@garyguo.net \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=lossin@kernel.org \
    --cc=nathan@kernel.org \
    --cc=nsc@kernel.org \
    --cc=ojeda@kernel.org \
    --cc=rust-for-linux@vger.kernel.org \
    --cc=tamird@kernel.org \
    --cc=tmgross@umich.edu \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox