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 <mar...@kurahaupo.gen.nz> Sent: Friday, December 6, 2024 2:53 PM To: Frederick Abell <fkabe...@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, <fkabe...@hotmail.com<mailto:fkabe...@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
