On Fri, 27 Feb 2026 at 04:19, Chet Ramey <[email protected]> wrote:

> It's ambiguous.  Both a binary in $PATH and a directory in the current
> directory can be valid completions, since bash completion (and readline)
> allows you to build a relative pathname by completing a directory at a
> time.
>
> Because it's ambiguous, the name exists as a directory in the current
> directory, and you have the `mark-directories' readline variable set,
> readline appends the slash.
>

I can follow this logic to see why it behaves as  it does, except that it
it's inconsistent.

If you have the full suite of vim installed then Bash shows a list like
this:
vim        vim.basic  vim.gtk3   vim.tiny   vimdiff    vimdot     vimplate
  vimtutor

Add a directory «vim» with «mark-directories» is in effect, and instead you
get:
vim/       vim.basic  vim.gtk3   vim.tiny   vimdiff    vimdot     vimplate
  vimtutor

which differs only in the addition of a trailing slash.

However, when you only have the vim directory and the vim command, with no
other commands machines that prefix, pressing tab shows a single-item list
vim
which has no slash, regardless of «mark-directories».

I contend that «vim» and «vim/» should count as separate completions; this
is consistent with:
(a) the behaviour of +o nospace (i.e., DO add a space after a unique
completion), which does NOT add a space when «vim» and «vim/» are the only
valid completions; and
(b) the decision to display a list of completions (when normally that
doesn't occur for a unique completion).

I suggest that these inconsistencies (and the original bug report) would be
resolved by showing both «vim» and «vim/» in the displayed list; in effect,
mark-directories would act to modify each element as it's added to the list
of completions, rather acting when when each item is displayed or used to
extend the completion.

-Martin

PS: «compopt +o nospace» is currently overridden by «bind 'set
mark-directories'». If directory marking occurs before terms are placed in
the list of valid completions, it then becomes necessary to apply a hidden
mark such entries to ensure the override remains in effect. This is
necessary so that +o nospace continues to insert a space when a unique
completion ending with a slash is NOT from matching a directory name.

PPS: Just in case anyone is inclined to suggest only the directory in the
list of valid "commands" should when there exists an executable file
somewhere within the directory, consider the abysmal performance when you
type “..<TAB>” when you're in, say, /etc.

Reply via email to