Bash tab not autocompleting node_module scoped folders starting with @ (at character)

I have the following weird behavior the following folder exists @fortawesome

But when I press

cd tabkey

none of the folders starting with "@" appears. Why does this happen/ how can I investigate it more?

Solution 1:

If you didnt make the directory using a linux system, there is a chance that bash complete, and therefore bash doesn't see it as a file.

A directory in Linux is actually just a file. that contains metadata, including the locations of the files that are "in" it. This is a lot different than the way Windows does it.

If the module (assuming that it is a node module) came from npm, there is a good chance that it was made by a NTFS file system.

I am not sure how this would affect the way bash completion sees it, but if it isn't showing, that is likely the reason.

How can I investigate it more.

To insure that the directory is still there you can just cd inside it. Either way, this will give you more info. Also, run ls -a ~ or la ~ if you have it.

You should also create a fresh folder with the same naming convention to see if it has the same issue.

Additionally, there is a tool you can get from apt called tree. It is like ls, but recursive. It will output the entire directory structure of the current directory.

To see if Linux has properly "accepted" the directory, you can check the permissions.

la -a -n

Pay attention to the very first character in the listing for the culprit directory. It should be a 'd'. If it is a '-', then it isn't a folder at all. It is now a file as far as the OS is concerned, which likely means that anything inside is wiped.

This will also show the owner & group info. If it has all these attributes, then it should definitely be showing up.

In this case, rerun the processes above & screenshot the result of each. If you add them to your question, I guarantee someone will know what is going on.

EDIT:

While I'm happy that you found a solution to the issue, I still can't help but wonder why this is the case on your machine and not mine. As I mentioned earlier, I lightly tested my own Ubuntu

(Ubuntu = version 20.04.2 -- bash = version 5.0.17release)

by making an @test directory and checking the results of running various commands & applications inside the same parent directory. I did this before you discovered that you could escape it. The issue is that they all worked as expected for me.

If it happened to you, and you are on a fairly current version of Ubuntu, then there will no doubt others with the same issue.

At the moment, I see two main possibilities as to the cause of the discrepancy. Either we've somehow run across some weird edge condition that nobody else has discovered yet (so unlikely that I feel a bit embarrassed just typing it.. XD), or else another program on your system is changing the behavior of the shell.

As I have hinted at in the comments, this is possible via manipulation of the shell environment. There are a few environment variables (in my 20.04 environment there are 11) which start with the pattern BASH, and point directly to the bash shell attributes. These are extremely easy to pinpoint, as they are all at the very beginning of the list that is displayed when you run the set command. If you pipe through less, as in:

set | less

they will be the first thing you see in the terminal display. While most of them are just meant as constants to provide access to info in your scripts, etc., and display the contained info (e.g. BASH_VERSION), others can control the info to which they reference. One such variable that stands out to me is BASHOPTS. If the behavior is, in fact , the result of a variable's value, this one would be a pretty good candidate for the culprit.

That said, one main purpose of the environment as a whole is to manipulate the shell's behavior. As a result, it could be any variable in your environment... or something completely different.

My purpose in continuing to troubleshoot this is so if anyone else comes here looking for a solution to this issue, they will not only know how to get around the issue, but what is causing it as well.

There is currently very little on the web about this issue (I couldn't find anything at all) and that in itself says a lot. This is never the case. No answers is rare enough, but no questions is nearly unheard of. Usually someone somewhere has had the same issue and posted about it.

NOTE:

By 'this is possible', I mean manipulation of bash's behavior in a general sense. I have no idea if it is possible to modify which characters bash sees as 'special.' That said, I can't see any other acceptable conclusions. I had to stretch a bit just to come to this one. If anybody else has any ideas, I am all ears.

Solution 2:

Because @ is a special character adding a backslash in beginning solved the problem. ie. cd \@tab while autocomplete correctly the names of the folders.