All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ryota Sakamoto <sakamo.ryota@gmail.com>
To: Jani Nikula <jani.nikula@intel.com>
Cc: Brendan Higgins <brendan.higgins@linux.dev>,
	 David Gow <davidgow@google.com>, Rae Moar <raemoar63@gmail.com>,
	Jonathan Corbet <corbet@lwn.net>,
	 linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org,
	kunit-dev@googlegroups.com,  workflows@vger.kernel.org,
	linux-doc@vger.kernel.org
Subject: Re: [PATCH] kunit: add bash completion
Date: Sat, 17 Jan 2026 02:16:04 +0900	[thread overview]
Message-ID: <aWpuYs0Mw6fR4rLO@fedora> (raw)
In-Reply-To: <44b770121202e9f41648da5abaf9a87d5b8811c6@intel.com>

Hi Jani,
Thank you for the suggestion regarding shtab.

On Fri, Jan 16, 2026 at 12:10:27PM +0200, Jani Nikula wrote:
> The alternative would be to make the tool more friendly to existing
> completion tools such as shtab [1]. Since the kernel as a project is
> really averse to adding external dependencies, you could take shtab's
> CLI approach, and commit the completion script in the repo. Only
> whoever's updating the completions would have to install and run shtab.

I understand your point about avoiding homebrew solutions, however, a main
benefit of this approach is that the completion script does not need to be
regenerated or updated manually.

Using shtab would introduce a new dependency and maintenance where the
static completion script could easily get out of sync.

So I would like to proceed with the current approach.

> And the whole thing could be taken a step further, adding, say,
> tools/completions/{bash,zsh,tcsh,...} directories for all the kernel
> tool completions instead of spreading them around.

I agree that centralizing completions is a good idea. So it would be better
handled as a separate future effort because it is a tree-wide
reorganization.

Regards,
Ryota Sakamoto

      reply	other threads:[~2026-01-16 17:16 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-15 14:53 [PATCH] kunit: add bash completion Ryota Sakamoto
2026-01-16  9:30 ` David Gow
2026-01-16 16:58   ` Ryota Sakamoto
2026-01-16 10:10 ` Jani Nikula
2026-01-16 17:16   ` Ryota Sakamoto [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=aWpuYs0Mw6fR4rLO@fedora \
    --to=sakamo.ryota@gmail.com \
    --cc=brendan.higgins@linux.dev \
    --cc=corbet@lwn.net \
    --cc=davidgow@google.com \
    --cc=jani.nikula@intel.com \
    --cc=kunit-dev@googlegroups.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=raemoar63@gmail.com \
    --cc=workflows@vger.kernel.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.