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?

  • proof you are using BASH :-) 2 files and 1 dir beginning with @ and bash autocomplete WILL pick the directory when you do cd {tab}. touch @1 @2 && mkdir @5 && ls @1 @2 @5 and cd {tab} makes it cd @5/
    – Rinzwind
    Jul 26 at 11:14
  • @Rinzwind Confirmed: I just tested on 20.04.2 (bash 5.0.17(1)-version). It displays my ~/@hello test directory, but it does ignore the @ symbol when deciding the sort order. Mine was in the 'H' section.
    – Nate T
    Jul 26 at 11:40
  • @OP what do you mean by node_module scoped folder? As in a node package?
    – Nate T
    Jul 26 at 11:46
  • I think it is because @ is a special character in bash. @Rinzwind echo "$SHELL" shows /bin/bash
    – partizanos
    Jul 26 at 12:09
  • @NateT I tought the issue might have been related with the fact it was a nod_modules scoped package (these are folders starting with @ character in their name by convention)
    – partizanos
    Jul 26 at 12:10

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.


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.


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.

  • Using the ls command the @XX folders appear successfully. The problem was when pressing cd @tabthat the @XX folders don't appear. It's as if @ is a special character in bash. (but I couldn't find where @ without $ in front ($@) has a special meaning gnu.org/software/bash/manual/bash.html ). Interesting scenario with NTFS if you have some example this happened maybe mention it in case someone faces the same issue (not my case since it is ubuntu based envrionment). Thanks for the help :)
    – partizanos
    Jul 26 at 16:55
  • I took too long to answer. I started right after my first comment, and by the time I finished, you hadd already solved it and answered. I guess that is the way it goes sometimes. The important thing is that you found a solution. I'll take a W based on that. That said, I'm still interested, because I ran a couple tests earlier, and my system doesn't treat it as a special char at all outside of regex applications like grep. This type of stuff always draws me in. XD ...did you ever check your bash version? Maybe the behavior was modified at some point.
    – Nate T
    Jul 26 at 18:34
  • Also, you should test it on another bash, like /usr/bin/bash. It may also be an env. variable set by a package installed on your system. When you run set, there are a few vaiables at the top of the list, some of which have the ability to modify the shell's default behavior in different ways.
    – Nate T
    Jul 26 at 18:44
  • Gonna move these (at least the relevant parts) to my answer so as to tidy up the comments.
    – Nate T
    Jul 26 at 18:52
  • My bash version from bash --version is 5.0.17(1)-release (x86_64-pc-linux-gnu)
    – partizanos
    Jul 27 at 7:44

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

  • My bash shows it regardless. What version are you on? bash --version. The shortcut doesn't work. It prints the input from .bashrc
    – Nate T
    Jul 26 at 12:39
  • My bash version from bash --version is 5.0.17(1)-release (x86_64-pc-linux-gnu). Which shortcut do you mean?
    – partizanos
    Jul 27 at 7:47
  • Buy shortcut, I just meant using the shorthand for the --version option, like bash - v. We have the exact same version of bash. It has to be another program causing your shell to modify its behavior. The question is which program and how exactly is it modifying. Were you able to check the value of BASHOPTS? The command is just echo $BASHOPTS
    – Nate T
    Jul 27 at 8:53
  • If you add it's value to your question, we can compare it against my value and maybe get a clue as to what's going on. It should be an array.
    – Nate T
    Jul 27 at 9:00
  • echo $BASHOPTS outputs checkwinsize:cmdhist:complete_fullquote:expand_aliases:extquote:force_fignore:globasciiranges:hostcomplete:interactive_comments:progcomp:promptvars:sourcepath
    – partizanos
    Jul 27 at 9:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.