Skip to content

feat: scheme-aware shell completion for scan targets#3437

Open
ChrisJr404 wants to merge 1 commit into
anchore:mainfrom
ChrisJr404:feat-completion-scheme-prefixes
Open

feat: scheme-aware shell completion for scan targets#3437
ChrisJr404 wants to merge 1 commit into
anchore:mainfrom
ChrisJr404:feat-completion-scheme-prefixes

Conversation

@ChrisJr404

Copy link
Copy Markdown

Closes #3432.

Problem

The root command's ValidArgsFunction (dockerImageValidArgsFunction in cmd/grype/cli/commands/completion.go) has only ever enumerated local Docker daemon images. Every other documented target scheme (registry:, oci-archive:, oci-dir:, singularity:, dir:, file:, sbom:, purl:, cpes:, podman:, docker-archive:) silently fell through to the shell, so a user typing <TAB> with no input sees nothing useful and a user typing oci-<TAB> gets no hint that oci-archive: or oci-dir: is even a legal prefix.

Change

dockerImageValidArgsFunction is now scheme-aware:

  • On an empty input, or a partial input that prefix-matches one or more known schemes, the documented scheme prefixes are returned alongside the docker-image suggestions. Each prefix carries its trailing : and the directive includes ShellCompDirectiveNoSpace so the user can keep typing the rest of the target (e.g. dir:./project) without the shell jumping to a fresh token.
  • For docker: and podman: inputs, the local docker daemon is queried with the scheme stripped, and the scheme is re-prepended onto each tag so the completion is a complete, valid grype argument.
  • For every other scheme prefix (file- or directory-backed: sbom:, dir:, oci-archive:, etc.), the function returns ShellCompDirectiveDefault so the shell does its own filename completion. That preserves the historical fallback rather than trying to second-guess what file extensions or directory shapes are valid for each scheme.

The scheme list lives in a single targetSchemePrefixes slice next to the function, and a coverage test pins it to every prefix documented in the root command's long-help text so the two won't drift.

Verification

  • go test ./cmd/grype/cli/commands/ passes.
  • Manual smoke against grype __complete "":
    • empty input lists all 12 scheme prefixes (and any local docker tags) with ShellCompDirectiveNoSpace
    • oci- narrows to oci-archive: and oci-dir:
    • dir:/tmp/ returns no suggestions and ShellCompDirectiveDefault, so the shell does path completion
    • docker: with no daemon falls through to the shell's default
  • go vet ./... is clean.

Notes for reviewers

I kept the function name dockerImageValidArgsFunction to minimize diff; happy to rename it to something like scanTargetValidArgsFunction if you'd prefer. I also resisted the urge to add per-scheme file-extension filters (sbom: to .json, oci-archive: to .tar) since several of those formats are accepted by extension and bare-name both, and a wrong filter would hurt UX more than it'd help.

The root command's ValidArgsFunction has only ever offered local
Docker images; every other documented target scheme (registry:,
oci-archive:, dir:, sbom:, purl:, ...) fell through to the shell
with no hint of what was even legal. Now we suggest the documented
scheme prefixes on an empty input or a partial match, dispatch to
the docker daemon for docker:/podman: prefixes, and defer to the
shell's file completion when a file/dir-based scheme is in play.

The scheme list mirrors the prefixes documented in the root
command's long-help text. NoSpace is set on the prefix completions
so the user can keep typing after the colon without the shell
treating ":" as a token boundary.

Closes anchore#3432

Signed-off-by: ChrisJr404 <chris@hacknow.com>
// targetSchemePrefixes is the set of scheme prefixes documented in the root command's long help text.
// Each entry includes the trailing ":" so that completion produces a value the user can keep typing
// after without having to add the separator themselves.
var targetSchemePrefixes = []string{

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for this PR. I think we will need to experiment with it to see if it "feels good" for real world use, but I would note that we have a --from flag which is also intended to replace the scheme. I'm not sure if autocompleting the scheme is ideal. We would also want to make sure the behavior is the same with --from specified.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Extend shell autocompletion to all scan target schemes

2 participants