On Wed, Oct 30, 2024 at 12:50:08PM +0100, Gioele Barabucci wrote: > On Wed, 31 Jul 2024 16:44:04 +0200 Lionel Elie Mamane <lio...@mamane.lu> > wrote: > > # STEP 1 > > $ touch a\$b > > $ touch a\$c > > $ ls > > 'a$b' 'a$c' > > $ b=GOTYA
> > # STEP 2 > > # now, type > > # ls <tab> > > # the resulting display is > > $ ls a$ > > # press <tab> again, the display is > > $ ls a$ > > a$b a$c > > $ ls a$ > > # STEP 3 > > # now, type "b" to complete the filename, the display is > > $ ls a$b > > # type <enter>, message is: > > ls: cannot access 'aGOTYA': No such file or directory > A fix for this issue is included in 5.2.32-1+b2. I installed 5.2.32-1+b2 and still reproduced exactly the behaviour you describe. I removed the ". /usr/share/bash-completion/bash_completion" and ". /etc/bash_completion" from my ~/.bashrc, verified they are not enabled (commented out) in /etc/bash.bashrc, opened a new terminal emulator (which thus spawns a new bash), and I still reproduce exactly the behaviour I describe. > > # type > > # ls <tab>* > > > > the result is: > > > > $ ls a$* > > ls: cannot access 'a': No such file or directory > > > > but after a <tab>, adding '*' should expand to all filenames possible, > > and her it does something else. > > *<TAB> does not normally expand to all filenames. > > $ cd $(mktemp -d) > $ touch aa ab ac bb > $ ls a*<TAB> > (no possible completion is shown) The report was not about "*<TAB>" but about "<TAB>*". The first <TAB> autocompletes to the common prefix of all files in the directory. In your example that is the empty string, in my example that is "a$" but with missing escaping of the "$". Since what the <TAB> autocompletes to is supposed to be the common prefix of all files in the directory, just typing "*<ENTER>" AFTER having pressed "<TAB>" should end up being all files in the directory, just as if <TAB> had not been pressed. Taking your example: $ ls <TAB> (no possible completion is shown, and no character is introduced) # now, type "*" and "enter" $ ls * aa ab ac bb # the result is all files in the directory (whose name does not start # with . to be completely precise) # similarly: $ rm bb $ ls <TAB> (the command line becomes automatically) $ ls a # now, type "*" and <enter> $ ls a* aa ab ac # the result is still all files in the directory (except .*) but in my example: $ ls <TAB> (the command line becomes automatically) $ ls a$ (should have become "ls a\$" instead) # now type "*<ENTER>" $ ls a$* ls: cannot access 'a': No such file or directory # but if <TAB> had auto-completed to "a\$", then we would have had $ ls a\$* 'a$b' 'a$c' #and all would be well > > $ echo a$b > > then pressing <tab> should NOT escape the '$' since that is not what > > was meant. > Why shouldn't it be escaped? The user requested that the second word of the command line the string "a" followed by the contents of the variable named b. Why would pressing <TAB> change that to the string "a$b"? > TAB is a request for filename completion (by > default/bashdefault). Inside this specific directory and given the > available list of files, I would say that a\$b is the correct > completion of a$b. My understanding of "filename completion" is that it completes the name of a file that starts with was is already on the word left of the current position of the cursor, taking into account the rules of typing things on the shell command line, especially with quoting, escaping, etc. So (assuming the corresponding files in the directory): - a\$b is a correct completion of any of: 'a$b' a\$b a\$ (the last one if that is the only completion, e.g. no file named 'a$c' exists) - but it is NOT a correct completion of a$b because the string "a$b" (without the double quotes) is NOT a valid beginning for typing the filename a$b on the command line. > bash-completing sets `complete -F _comp_complete_minimal echo` (i.e., > bashdefault). If you think echo should get its own set of completion rules, > could you please file a bug against bash-completion? This has nothing to do with the command "echo", that was just an example. The command could be "touch", "ls", "cat", "rm" or anything else. Assume there is a file named "aGOTYA" in the directory if it makes the example more clear to you. If the user typed rm a$b (s)he asked for the file aGOTYA to be deleted; it is not OK for filename autocompletion to change that to deleting another file named 'a\$b'. It is OK for autocompletion to not be "intelligent" enough to expand a$b to aGOTYAreally (if there is that file in the directory) because it doesn't go look into the value of the variable named b, it is just not that refined. It is OK to rewrite 'a$b' into a\$b since that has the exact same meaning. But changing what the user typed to mean something else is IMHO not OK.
