Re: `complete -f` does not work at all.

[Frederick Abell]

Martin and Chet,

Thank you both for the quick reply and clarification.  I made an
account and replied to the thread as per Martin's request.

> `complete -f' is basically the same as readline's filename completion,
> which includes directories in the list of possible completions because
> filenames can appear in subdirectories of the current directory

After reading that, I have decided that I do not want to change the
default behaviour.

> Firstly this seems to be You seem to be under the misapprehension
> that directories are not files. Unless specified otherwise "file"
> means any kind of inode.

This does not appear to be the case in some other GNU documentation.
GNU cat(1) does not state anything about regular files but will
obviously fail when cat's argument is a file with a S_IFDIR inode.  In
my inexperienced opinion, I think that the bash(1) man page should be
edited to indicate `complete -A file' works with anything with an inode,
instead of stating the phrase "Files names.".

Thanks again,
Freddie Abell

________________________________
From: Martin D Kealey <martin@kurahaupo.gen.nz>
Sent: Friday, December 6, 2024 2:53 PM
To: Frederick Abell <fkabell3@hotmail.com>
Cc: bug-bash <bug-bash@gnu.org>
Subject: Re: `complete -f` does not work at all.



On Fri, 6 Dec 2024, 15:12 Frederick Abell, 
<fkabell3@hotmail.com<mailto:fkabell3@hotmail.com>> wrote:
Description:
`compete -f`/`complete -A file` do not work at all, whilst `complete 
-d`/`complete -A directory` work fine.

$ cat <tab>
a_dir/  b_dir/  c_file  d_file

# I was expecting to only see c_file and d_file.

Firstly this seems to be You seem to be under the misapprehension that 
directories are not files. Unless specified otherwise "file" means any kind of 
inode.

Secondly, even if you do think that “complete -f” is (or should be) restricted 
to S_ISREG inodes, completions only generate one path component at a time.

Try this:
  mkdir -p e/f/g/h
  touch e/f/g/h/i

  cat e‹tab›‹tab›‹tab›‹tab›‹tab›

Now does the behaviour make more sense?

As for “why not generate full paths”, it can be prohibitively expensive to look 
recursively inside each subdirectory to see whether it contains any files. 
Consider what doing this would mean if you typed:

  cat /‹tab›‹tab›

If you're still in doubt, run:

  time find / > /dev/null

It can also be literally impossible to generate all possible full paths; try 
this

  rm e/f/g/h/i
  ln -s ../../../e e/f/g/h/i
  cat e‹tab›‹tab›‹tab›‹tab›‹tab›‹tab›‹tab›‹tab›‹tab›‹tab›

> Someone from 2008 appears to have the same issue

Ah yes, the internet, an infinite source of misinformation and 
misunderstanding. Now that you understand the issue, please add a new reply to 
that page.

-Martin