What does the period (.) mean at the start of a filename in a terminal command?

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP











up vote
6
down vote

favorite












In chmod -R 421 .gimp, what does the period mean directly preceding the g in gimp? Is that similar to the * wildcard?










share|improve this question



















  • 1




    Also see Is it bad practice for folder name to contain dot (.)? How about file name with multiple dots?
    – user68186
    Sep 5 at 13:53






  • 3




    The short answer is that the . doesn't "do" anything; the shell interprets it as a literal period character. Programs such as ls can choose what to do when they see a leading period, though.
    – BallpointBen
    Sep 5 at 15:33














up vote
6
down vote

favorite












In chmod -R 421 .gimp, what does the period mean directly preceding the g in gimp? Is that similar to the * wildcard?










share|improve this question



















  • 1




    Also see Is it bad practice for folder name to contain dot (.)? How about file name with multiple dots?
    – user68186
    Sep 5 at 13:53






  • 3




    The short answer is that the . doesn't "do" anything; the shell interprets it as a literal period character. Programs such as ls can choose what to do when they see a leading period, though.
    – BallpointBen
    Sep 5 at 15:33












up vote
6
down vote

favorite









up vote
6
down vote

favorite











In chmod -R 421 .gimp, what does the period mean directly preceding the g in gimp? Is that similar to the * wildcard?










share|improve this question















In chmod -R 421 .gimp, what does the period mean directly preceding the g in gimp? Is that similar to the * wildcard?







command-line hidden-files






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Sep 6 at 7:30









Olorin

1,678619




1,678619










asked Sep 5 at 13:32









stackinator

365112




365112







  • 1




    Also see Is it bad practice for folder name to contain dot (.)? How about file name with multiple dots?
    – user68186
    Sep 5 at 13:53






  • 3




    The short answer is that the . doesn't "do" anything; the shell interprets it as a literal period character. Programs such as ls can choose what to do when they see a leading period, though.
    – BallpointBen
    Sep 5 at 15:33












  • 1




    Also see Is it bad practice for folder name to contain dot (.)? How about file name with multiple dots?
    – user68186
    Sep 5 at 13:53






  • 3




    The short answer is that the . doesn't "do" anything; the shell interprets it as a literal period character. Programs such as ls can choose what to do when they see a leading period, though.
    – BallpointBen
    Sep 5 at 15:33







1




1




Also see Is it bad practice for folder name to contain dot (.)? How about file name with multiple dots?
– user68186
Sep 5 at 13:53




Also see Is it bad practice for folder name to contain dot (.)? How about file name with multiple dots?
– user68186
Sep 5 at 13:53




3




3




The short answer is that the . doesn't "do" anything; the shell interprets it as a literal period character. Programs such as ls can choose what to do when they see a leading period, though.
– BallpointBen
Sep 5 at 15:33




The short answer is that the . doesn't "do" anything; the shell interprets it as a literal period character. Programs such as ls can choose what to do when they see a leading period, though.
– BallpointBen
Sep 5 at 15:33










5 Answers
5






active

oldest

votes

















up vote
19
down vote



accepted










The dot in that situation is part of the filename and has in the Linux/Unix context the meaning that the file or directory is hidden, you cannot see it in the file explorer (Nautilus, which is default on the vanilla Ubuntu), unless you press CTRL+H.



And, if you only use ls in the terminal, you will not see it either unless you use the -a or -A flag with it (i.e. ls -a or ls -A or ls --all or ls --almost-all).



However, the dot (.) has different meanings in different contexts:



  • For example in a path (./file) it describes the current directory you are in, while ../file refers to file in the parent directory.

  • And there is even a command . which sources (runs) bash script files. So . ./file (mind the spacing) would source the script named file in the current directory.

  • and in a REGEX context, the dot means "any character".





share|improve this answer






















  • cp or mv to the current directory might be a good example too
    – Azor Ahai
    Sep 5 at 15:42






  • 6




    I think this answer would be better served by being more explicit: That in this case, the dot doesn't mean anything; it's just part of the filename. Nautilus, as a side note, hides all files whose names start with dots. The rest of the information about how . is used is quite useful, though, and it should definitely stay.
    – Nic Hartley
    Sep 5 at 20:49






  • 1




    @NicHartley I disagree. The leading dot is part of the name but it carries meaning of a hidden file, at least by Unix convention. In cases such as ~/.bashrc removing that leading dot would cause file being not sourced by bash. So often that leading dot is meaningful.
    – Sergiy Kolodyazhnyy
    Sep 6 at 7:44







  • 2




    The leading dot is meaningful, but only because it's part of the filename...
    – Josh
    Sep 6 at 9:17










  • @SergiyKolodyazhnyy Bash expects a file named .bashrc in the user's home directory, not some magical combination of a filesystem flag and the filename bashrc. The fact that it contains a dot is literally completely irrelevant; it just matches with Unix conventions. So, no, the dot doesn't mean anything, in the same way extensions don't. There are conventions in place to use it in certain situations, but the OS gives zero-- er, cares. As the answer is written now, it explains it nicely (albeit compactly): It's a part of the filename; it's given extra meaning by how software treats it.
    – Nic Hartley
    Sep 6 at 16:24


















up vote
19
down vote













.gimp in your example is a filename, the "." is the first character.



The significance of it is a normal ls (ls=list files) won't show files with "." as the first character, it only lists with ls -a (or list files --all)






share|improve this answer




















  • actually that .gimp is hidden directory not a file
    – Î±Ò“sнιη
    Sep 5 at 18:16






  • 11




    @αғsнιη A directory is still a file, if we're being pedantic.
    – NieDzejkob
    Sep 5 at 19:06










  • @NieDzejkob technically speaking, then there is no file either or directory or whatever; all are an inode.
    – Î±Ò“sнιη
    Sep 10 at 3:08

















up vote
5
down vote













Nothing. It's part of the filename.



You appear to have a directory called .gimp.



Period. (lol)



Any other discussion about it belongs in a question about why people choose certain filenames for things.






share|improve this answer






















  • "...why people choose certain filenames for things" Often people don't choose filenames, but filenames are standard, such as config file/directory filename
    – Sergiy Kolodyazhnyy
    Sep 6 at 7:46






  • 2




    Joined and upvoted just for the period joke.
    – return true
    Sep 6 at 7:58










  • @SergiyKolodyazhnyy Somebody still came up with those :P
    – Lightness Races in Orbit
    Sep 6 at 10:46










  • @LightnessRacesinOrbit Lol, OK, fair enough, I can agree with that. As a developer, one can choose what filenames to use. Some of my indicators use leading dot for config files in user's home directory, others - do not for files in ~/.config. But that choice also carries meaning and adheres to standards. A file ~/.config/.mything would be unconventional and confusing to users and be a sign of bad practice to other developers.
    – Sergiy Kolodyazhnyy
    Sep 6 at 12:42










  • @SergiyKolodyazhnyy Yep I'm just being deliberately difficult about it to hammer home the point that . has no special meaning to the shell, contrary to the premise of the question
    – Lightness Races in Orbit
    Sep 6 at 12:43

















up vote
4
down vote













The leading dot in file or directory names doesn't carry any particular significance, as far as Linux itself is concerned. However, certain utilities (such as ls or Nautilus file manager) consider such filenames as "hidden", that is they ignore them in their output, and will only show them if you provide a specific option.



In reality, this originated with what technically can be considered a bug. Rob Pike, one of the original people who worked on UNIX team recounts (source):




Long ago, as the design of the Unix file system was being worked out, the entries . and .. appeared, to make navigation easier. I'm not sure but I believe .. went in during the Version 2 rewrite, when the file system became hierarchical (it had a very different structure early on). When one typed ls, however, these files appeared, so either Ken or Dennis added a simple test to the program. It was in assembler then, but the code in question was equivalent to something like this:



 if (name[0] == '.') continue;


This statement was a little shorter than what it should have been, which is



 if (strcmp(name, ".") == 0 || strcmp(name, "..") == 0) continue;


but hey, it was easy.



Two things resulted.



First, a bad precedent was set. A lot of other lazy programmers introduced bugs by making the same simplification. Actual files beginning with periods are often skipped when they should be counted.



Second, and much worse, the idea of a "hidden" or "dot" file was created. As a consequence, more lazy programmers started dropping files into everyone's home directory. I don't have all that much stuff installed on the machine I'm using to type this, but my home directory has about a hundred dot files and I don't even know what most of them are or whether they're still needed. Every file name evaluation that goes through my home directory is slowed down by this accumulated sludge.



I'm pretty sure the concept of a hidden file was an unintended consequence. It was certainly a mistake.




Nowadays, this sort of became a convention to call them "hidden" even though their contents are not hidden at all. A real hidden, or anonymous file/anonymous inode, would be implemented via opening file and holding its file descriptor open, but unlinking it from the directory, which makes the data itself to be accessible only to the program that is holding that file, and its child processes (preferably forked after unlinking the file), since child processes inherit file descriptors. In fact, this is how bash implements here-docs.



Very different story is when filename is itself a dot . or .., which actually have a bit of history behind them, and I suggest you read Why is the current directory in the ls command identified as linked to itself?






share|improve this answer





























    up vote
    3
    down vote













    A dot at the beginning of a filename hides the file in common file managers and for common shell programs.



    The reason is historical, when ls hid the special directories . and .. by hiding everything which starts with a period. Then people used filenames starting with a period to hide files, so they are only listed with ls -a, for example to make configuration files invisible which are not needed in the ls output usually.



    So the dot in chmod -R 421 .gimp is not a modifier of the command, but a part of the actual directory name.






    share|improve this answer




















      Your Answer







      StackExchange.ready(function()
      var channelOptions =
      tags: "".split(" "),
      id: "89"
      ;
      initTagRenderer("".split(" "), "".split(" "), channelOptions);

      StackExchange.using("externalEditor", function()
      // Have to fire editor after snippets, if snippets enabled
      if (StackExchange.settings.snippets.snippetsEnabled)
      StackExchange.using("snippets", function()
      createEditor();
      );

      else
      createEditor();

      );

      function createEditor()
      StackExchange.prepareEditor(
      heartbeatType: 'answer',
      convertImagesToLinks: true,
      noModals: false,
      showLowRepImageUploadWarning: true,
      reputationToPostImages: 10,
      bindNavPrevention: true,
      postfix: "",
      onDemand: true,
      discardSelector: ".discard-answer"
      ,immediatelyShowMarkdownHelp:true
      );



      );













       

      draft saved


      draft discarded


















      StackExchange.ready(
      function ()
      StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f1072377%2fwhat-does-the-period-mean-at-the-start-of-a-filename-in-a-terminal-command%23new-answer', 'question_page');

      );

      Post as a guest






























      5 Answers
      5






      active

      oldest

      votes








      5 Answers
      5






      active

      oldest

      votes









      active

      oldest

      votes






      active

      oldest

      votes








      up vote
      19
      down vote



      accepted










      The dot in that situation is part of the filename and has in the Linux/Unix context the meaning that the file or directory is hidden, you cannot see it in the file explorer (Nautilus, which is default on the vanilla Ubuntu), unless you press CTRL+H.



      And, if you only use ls in the terminal, you will not see it either unless you use the -a or -A flag with it (i.e. ls -a or ls -A or ls --all or ls --almost-all).



      However, the dot (.) has different meanings in different contexts:



      • For example in a path (./file) it describes the current directory you are in, while ../file refers to file in the parent directory.

      • And there is even a command . which sources (runs) bash script files. So . ./file (mind the spacing) would source the script named file in the current directory.

      • and in a REGEX context, the dot means "any character".





      share|improve this answer






















      • cp or mv to the current directory might be a good example too
        – Azor Ahai
        Sep 5 at 15:42






      • 6




        I think this answer would be better served by being more explicit: That in this case, the dot doesn't mean anything; it's just part of the filename. Nautilus, as a side note, hides all files whose names start with dots. The rest of the information about how . is used is quite useful, though, and it should definitely stay.
        – Nic Hartley
        Sep 5 at 20:49






      • 1




        @NicHartley I disagree. The leading dot is part of the name but it carries meaning of a hidden file, at least by Unix convention. In cases such as ~/.bashrc removing that leading dot would cause file being not sourced by bash. So often that leading dot is meaningful.
        – Sergiy Kolodyazhnyy
        Sep 6 at 7:44







      • 2




        The leading dot is meaningful, but only because it's part of the filename...
        – Josh
        Sep 6 at 9:17










      • @SergiyKolodyazhnyy Bash expects a file named .bashrc in the user's home directory, not some magical combination of a filesystem flag and the filename bashrc. The fact that it contains a dot is literally completely irrelevant; it just matches with Unix conventions. So, no, the dot doesn't mean anything, in the same way extensions don't. There are conventions in place to use it in certain situations, but the OS gives zero-- er, cares. As the answer is written now, it explains it nicely (albeit compactly): It's a part of the filename; it's given extra meaning by how software treats it.
        – Nic Hartley
        Sep 6 at 16:24















      up vote
      19
      down vote



      accepted










      The dot in that situation is part of the filename and has in the Linux/Unix context the meaning that the file or directory is hidden, you cannot see it in the file explorer (Nautilus, which is default on the vanilla Ubuntu), unless you press CTRL+H.



      And, if you only use ls in the terminal, you will not see it either unless you use the -a or -A flag with it (i.e. ls -a or ls -A or ls --all or ls --almost-all).



      However, the dot (.) has different meanings in different contexts:



      • For example in a path (./file) it describes the current directory you are in, while ../file refers to file in the parent directory.

      • And there is even a command . which sources (runs) bash script files. So . ./file (mind the spacing) would source the script named file in the current directory.

      • and in a REGEX context, the dot means "any character".





      share|improve this answer






















      • cp or mv to the current directory might be a good example too
        – Azor Ahai
        Sep 5 at 15:42






      • 6




        I think this answer would be better served by being more explicit: That in this case, the dot doesn't mean anything; it's just part of the filename. Nautilus, as a side note, hides all files whose names start with dots. The rest of the information about how . is used is quite useful, though, and it should definitely stay.
        – Nic Hartley
        Sep 5 at 20:49






      • 1




        @NicHartley I disagree. The leading dot is part of the name but it carries meaning of a hidden file, at least by Unix convention. In cases such as ~/.bashrc removing that leading dot would cause file being not sourced by bash. So often that leading dot is meaningful.
        – Sergiy Kolodyazhnyy
        Sep 6 at 7:44







      • 2




        The leading dot is meaningful, but only because it's part of the filename...
        – Josh
        Sep 6 at 9:17










      • @SergiyKolodyazhnyy Bash expects a file named .bashrc in the user's home directory, not some magical combination of a filesystem flag and the filename bashrc. The fact that it contains a dot is literally completely irrelevant; it just matches with Unix conventions. So, no, the dot doesn't mean anything, in the same way extensions don't. There are conventions in place to use it in certain situations, but the OS gives zero-- er, cares. As the answer is written now, it explains it nicely (albeit compactly): It's a part of the filename; it's given extra meaning by how software treats it.
        – Nic Hartley
        Sep 6 at 16:24













      up vote
      19
      down vote



      accepted







      up vote
      19
      down vote



      accepted






      The dot in that situation is part of the filename and has in the Linux/Unix context the meaning that the file or directory is hidden, you cannot see it in the file explorer (Nautilus, which is default on the vanilla Ubuntu), unless you press CTRL+H.



      And, if you only use ls in the terminal, you will not see it either unless you use the -a or -A flag with it (i.e. ls -a or ls -A or ls --all or ls --almost-all).



      However, the dot (.) has different meanings in different contexts:



      • For example in a path (./file) it describes the current directory you are in, while ../file refers to file in the parent directory.

      • And there is even a command . which sources (runs) bash script files. So . ./file (mind the spacing) would source the script named file in the current directory.

      • and in a REGEX context, the dot means "any character".





      share|improve this answer














      The dot in that situation is part of the filename and has in the Linux/Unix context the meaning that the file or directory is hidden, you cannot see it in the file explorer (Nautilus, which is default on the vanilla Ubuntu), unless you press CTRL+H.



      And, if you only use ls in the terminal, you will not see it either unless you use the -a or -A flag with it (i.e. ls -a or ls -A or ls --all or ls --almost-all).



      However, the dot (.) has different meanings in different contexts:



      • For example in a path (./file) it describes the current directory you are in, while ../file refers to file in the parent directory.

      • And there is even a command . which sources (runs) bash script files. So . ./file (mind the spacing) would source the script named file in the current directory.

      • and in a REGEX context, the dot means "any character".






      share|improve this answer














      share|improve this answer



      share|improve this answer








      edited Sep 20 at 2:40

























      answered Sep 5 at 13:36









      Videonauth

      22.5k116897




      22.5k116897











      • cp or mv to the current directory might be a good example too
        – Azor Ahai
        Sep 5 at 15:42






      • 6




        I think this answer would be better served by being more explicit: That in this case, the dot doesn't mean anything; it's just part of the filename. Nautilus, as a side note, hides all files whose names start with dots. The rest of the information about how . is used is quite useful, though, and it should definitely stay.
        – Nic Hartley
        Sep 5 at 20:49






      • 1




        @NicHartley I disagree. The leading dot is part of the name but it carries meaning of a hidden file, at least by Unix convention. In cases such as ~/.bashrc removing that leading dot would cause file being not sourced by bash. So often that leading dot is meaningful.
        – Sergiy Kolodyazhnyy
        Sep 6 at 7:44







      • 2




        The leading dot is meaningful, but only because it's part of the filename...
        – Josh
        Sep 6 at 9:17










      • @SergiyKolodyazhnyy Bash expects a file named .bashrc in the user's home directory, not some magical combination of a filesystem flag and the filename bashrc. The fact that it contains a dot is literally completely irrelevant; it just matches with Unix conventions. So, no, the dot doesn't mean anything, in the same way extensions don't. There are conventions in place to use it in certain situations, but the OS gives zero-- er, cares. As the answer is written now, it explains it nicely (albeit compactly): It's a part of the filename; it's given extra meaning by how software treats it.
        – Nic Hartley
        Sep 6 at 16:24

















      • cp or mv to the current directory might be a good example too
        – Azor Ahai
        Sep 5 at 15:42






      • 6




        I think this answer would be better served by being more explicit: That in this case, the dot doesn't mean anything; it's just part of the filename. Nautilus, as a side note, hides all files whose names start with dots. The rest of the information about how . is used is quite useful, though, and it should definitely stay.
        – Nic Hartley
        Sep 5 at 20:49






      • 1




        @NicHartley I disagree. The leading dot is part of the name but it carries meaning of a hidden file, at least by Unix convention. In cases such as ~/.bashrc removing that leading dot would cause file being not sourced by bash. So often that leading dot is meaningful.
        – Sergiy Kolodyazhnyy
        Sep 6 at 7:44







      • 2




        The leading dot is meaningful, but only because it's part of the filename...
        – Josh
        Sep 6 at 9:17










      • @SergiyKolodyazhnyy Bash expects a file named .bashrc in the user's home directory, not some magical combination of a filesystem flag and the filename bashrc. The fact that it contains a dot is literally completely irrelevant; it just matches with Unix conventions. So, no, the dot doesn't mean anything, in the same way extensions don't. There are conventions in place to use it in certain situations, but the OS gives zero-- er, cares. As the answer is written now, it explains it nicely (albeit compactly): It's a part of the filename; it's given extra meaning by how software treats it.
        – Nic Hartley
        Sep 6 at 16:24
















      cp or mv to the current directory might be a good example too
      – Azor Ahai
      Sep 5 at 15:42




      cp or mv to the current directory might be a good example too
      – Azor Ahai
      Sep 5 at 15:42




      6




      6




      I think this answer would be better served by being more explicit: That in this case, the dot doesn't mean anything; it's just part of the filename. Nautilus, as a side note, hides all files whose names start with dots. The rest of the information about how . is used is quite useful, though, and it should definitely stay.
      – Nic Hartley
      Sep 5 at 20:49




      I think this answer would be better served by being more explicit: That in this case, the dot doesn't mean anything; it's just part of the filename. Nautilus, as a side note, hides all files whose names start with dots. The rest of the information about how . is used is quite useful, though, and it should definitely stay.
      – Nic Hartley
      Sep 5 at 20:49




      1




      1




      @NicHartley I disagree. The leading dot is part of the name but it carries meaning of a hidden file, at least by Unix convention. In cases such as ~/.bashrc removing that leading dot would cause file being not sourced by bash. So often that leading dot is meaningful.
      – Sergiy Kolodyazhnyy
      Sep 6 at 7:44





      @NicHartley I disagree. The leading dot is part of the name but it carries meaning of a hidden file, at least by Unix convention. In cases such as ~/.bashrc removing that leading dot would cause file being not sourced by bash. So often that leading dot is meaningful.
      – Sergiy Kolodyazhnyy
      Sep 6 at 7:44





      2




      2




      The leading dot is meaningful, but only because it's part of the filename...
      – Josh
      Sep 6 at 9:17




      The leading dot is meaningful, but only because it's part of the filename...
      – Josh
      Sep 6 at 9:17












      @SergiyKolodyazhnyy Bash expects a file named .bashrc in the user's home directory, not some magical combination of a filesystem flag and the filename bashrc. The fact that it contains a dot is literally completely irrelevant; it just matches with Unix conventions. So, no, the dot doesn't mean anything, in the same way extensions don't. There are conventions in place to use it in certain situations, but the OS gives zero-- er, cares. As the answer is written now, it explains it nicely (albeit compactly): It's a part of the filename; it's given extra meaning by how software treats it.
      – Nic Hartley
      Sep 6 at 16:24





      @SergiyKolodyazhnyy Bash expects a file named .bashrc in the user's home directory, not some magical combination of a filesystem flag and the filename bashrc. The fact that it contains a dot is literally completely irrelevant; it just matches with Unix conventions. So, no, the dot doesn't mean anything, in the same way extensions don't. There are conventions in place to use it in certain situations, but the OS gives zero-- er, cares. As the answer is written now, it explains it nicely (albeit compactly): It's a part of the filename; it's given extra meaning by how software treats it.
      – Nic Hartley
      Sep 6 at 16:24













      up vote
      19
      down vote













      .gimp in your example is a filename, the "." is the first character.



      The significance of it is a normal ls (ls=list files) won't show files with "." as the first character, it only lists with ls -a (or list files --all)






      share|improve this answer




















      • actually that .gimp is hidden directory not a file
        – Î±Ò“sнιη
        Sep 5 at 18:16






      • 11




        @αғsнιη A directory is still a file, if we're being pedantic.
        – NieDzejkob
        Sep 5 at 19:06










      • @NieDzejkob technically speaking, then there is no file either or directory or whatever; all are an inode.
        – Î±Ò“sнιη
        Sep 10 at 3:08














      up vote
      19
      down vote













      .gimp in your example is a filename, the "." is the first character.



      The significance of it is a normal ls (ls=list files) won't show files with "." as the first character, it only lists with ls -a (or list files --all)






      share|improve this answer




















      • actually that .gimp is hidden directory not a file
        – Î±Ò“sнιη
        Sep 5 at 18:16






      • 11




        @αғsнιη A directory is still a file, if we're being pedantic.
        – NieDzejkob
        Sep 5 at 19:06










      • @NieDzejkob technically speaking, then there is no file either or directory or whatever; all are an inode.
        – Î±Ò“sнιη
        Sep 10 at 3:08












      up vote
      19
      down vote










      up vote
      19
      down vote









      .gimp in your example is a filename, the "." is the first character.



      The significance of it is a normal ls (ls=list files) won't show files with "." as the first character, it only lists with ls -a (or list files --all)






      share|improve this answer












      .gimp in your example is a filename, the "." is the first character.



      The significance of it is a normal ls (ls=list files) won't show files with "." as the first character, it only lists with ls -a (or list files --all)







      share|improve this answer












      share|improve this answer



      share|improve this answer










      answered Sep 5 at 13:37









      guiverc

      3,72811422




      3,72811422











      • actually that .gimp is hidden directory not a file
        – Î±Ò“sнιη
        Sep 5 at 18:16






      • 11




        @αғsнιη A directory is still a file, if we're being pedantic.
        – NieDzejkob
        Sep 5 at 19:06










      • @NieDzejkob technically speaking, then there is no file either or directory or whatever; all are an inode.
        – Î±Ò“sнιη
        Sep 10 at 3:08
















      • actually that .gimp is hidden directory not a file
        – Î±Ò“sнιη
        Sep 5 at 18:16






      • 11




        @αғsнιη A directory is still a file, if we're being pedantic.
        – NieDzejkob
        Sep 5 at 19:06










      • @NieDzejkob technically speaking, then there is no file either or directory or whatever; all are an inode.
        – Î±Ò“sнιη
        Sep 10 at 3:08















      actually that .gimp is hidden directory not a file
      – Î±Ò“sнιη
      Sep 5 at 18:16




      actually that .gimp is hidden directory not a file
      – Î±Ò“sнιη
      Sep 5 at 18:16




      11




      11




      @αғsнιη A directory is still a file, if we're being pedantic.
      – NieDzejkob
      Sep 5 at 19:06




      @αғsнιη A directory is still a file, if we're being pedantic.
      – NieDzejkob
      Sep 5 at 19:06












      @NieDzejkob technically speaking, then there is no file either or directory or whatever; all are an inode.
      – Î±Ò“sнιη
      Sep 10 at 3:08




      @NieDzejkob technically speaking, then there is no file either or directory or whatever; all are an inode.
      – Î±Ò“sнιη
      Sep 10 at 3:08










      up vote
      5
      down vote













      Nothing. It's part of the filename.



      You appear to have a directory called .gimp.



      Period. (lol)



      Any other discussion about it belongs in a question about why people choose certain filenames for things.






      share|improve this answer






















      • "...why people choose certain filenames for things" Often people don't choose filenames, but filenames are standard, such as config file/directory filename
        – Sergiy Kolodyazhnyy
        Sep 6 at 7:46






      • 2




        Joined and upvoted just for the period joke.
        – return true
        Sep 6 at 7:58










      • @SergiyKolodyazhnyy Somebody still came up with those :P
        – Lightness Races in Orbit
        Sep 6 at 10:46










      • @LightnessRacesinOrbit Lol, OK, fair enough, I can agree with that. As a developer, one can choose what filenames to use. Some of my indicators use leading dot for config files in user's home directory, others - do not for files in ~/.config. But that choice also carries meaning and adheres to standards. A file ~/.config/.mything would be unconventional and confusing to users and be a sign of bad practice to other developers.
        – Sergiy Kolodyazhnyy
        Sep 6 at 12:42










      • @SergiyKolodyazhnyy Yep I'm just being deliberately difficult about it to hammer home the point that . has no special meaning to the shell, contrary to the premise of the question
        – Lightness Races in Orbit
        Sep 6 at 12:43














      up vote
      5
      down vote













      Nothing. It's part of the filename.



      You appear to have a directory called .gimp.



      Period. (lol)



      Any other discussion about it belongs in a question about why people choose certain filenames for things.






      share|improve this answer






















      • "...why people choose certain filenames for things" Often people don't choose filenames, but filenames are standard, such as config file/directory filename
        – Sergiy Kolodyazhnyy
        Sep 6 at 7:46






      • 2




        Joined and upvoted just for the period joke.
        – return true
        Sep 6 at 7:58










      • @SergiyKolodyazhnyy Somebody still came up with those :P
        – Lightness Races in Orbit
        Sep 6 at 10:46










      • @LightnessRacesinOrbit Lol, OK, fair enough, I can agree with that. As a developer, one can choose what filenames to use. Some of my indicators use leading dot for config files in user's home directory, others - do not for files in ~/.config. But that choice also carries meaning and adheres to standards. A file ~/.config/.mything would be unconventional and confusing to users and be a sign of bad practice to other developers.
        – Sergiy Kolodyazhnyy
        Sep 6 at 12:42










      • @SergiyKolodyazhnyy Yep I'm just being deliberately difficult about it to hammer home the point that . has no special meaning to the shell, contrary to the premise of the question
        – Lightness Races in Orbit
        Sep 6 at 12:43












      up vote
      5
      down vote










      up vote
      5
      down vote









      Nothing. It's part of the filename.



      You appear to have a directory called .gimp.



      Period. (lol)



      Any other discussion about it belongs in a question about why people choose certain filenames for things.






      share|improve this answer














      Nothing. It's part of the filename.



      You appear to have a directory called .gimp.



      Period. (lol)



      Any other discussion about it belongs in a question about why people choose certain filenames for things.







      share|improve this answer














      share|improve this answer



      share|improve this answer








      edited Sep 5 at 23:25

























      answered Sep 5 at 17:35









      Lightness Races in Orbit

      308110




      308110











      • "...why people choose certain filenames for things" Often people don't choose filenames, but filenames are standard, such as config file/directory filename
        – Sergiy Kolodyazhnyy
        Sep 6 at 7:46






      • 2




        Joined and upvoted just for the period joke.
        – return true
        Sep 6 at 7:58










      • @SergiyKolodyazhnyy Somebody still came up with those :P
        – Lightness Races in Orbit
        Sep 6 at 10:46










      • @LightnessRacesinOrbit Lol, OK, fair enough, I can agree with that. As a developer, one can choose what filenames to use. Some of my indicators use leading dot for config files in user's home directory, others - do not for files in ~/.config. But that choice also carries meaning and adheres to standards. A file ~/.config/.mything would be unconventional and confusing to users and be a sign of bad practice to other developers.
        – Sergiy Kolodyazhnyy
        Sep 6 at 12:42










      • @SergiyKolodyazhnyy Yep I'm just being deliberately difficult about it to hammer home the point that . has no special meaning to the shell, contrary to the premise of the question
        – Lightness Races in Orbit
        Sep 6 at 12:43
















      • "...why people choose certain filenames for things" Often people don't choose filenames, but filenames are standard, such as config file/directory filename
        – Sergiy Kolodyazhnyy
        Sep 6 at 7:46






      • 2




        Joined and upvoted just for the period joke.
        – return true
        Sep 6 at 7:58










      • @SergiyKolodyazhnyy Somebody still came up with those :P
        – Lightness Races in Orbit
        Sep 6 at 10:46










      • @LightnessRacesinOrbit Lol, OK, fair enough, I can agree with that. As a developer, one can choose what filenames to use. Some of my indicators use leading dot for config files in user's home directory, others - do not for files in ~/.config. But that choice also carries meaning and adheres to standards. A file ~/.config/.mything would be unconventional and confusing to users and be a sign of bad practice to other developers.
        – Sergiy Kolodyazhnyy
        Sep 6 at 12:42










      • @SergiyKolodyazhnyy Yep I'm just being deliberately difficult about it to hammer home the point that . has no special meaning to the shell, contrary to the premise of the question
        – Lightness Races in Orbit
        Sep 6 at 12:43















      "...why people choose certain filenames for things" Often people don't choose filenames, but filenames are standard, such as config file/directory filename
      – Sergiy Kolodyazhnyy
      Sep 6 at 7:46




      "...why people choose certain filenames for things" Often people don't choose filenames, but filenames are standard, such as config file/directory filename
      – Sergiy Kolodyazhnyy
      Sep 6 at 7:46




      2




      2




      Joined and upvoted just for the period joke.
      – return true
      Sep 6 at 7:58




      Joined and upvoted just for the period joke.
      – return true
      Sep 6 at 7:58












      @SergiyKolodyazhnyy Somebody still came up with those :P
      – Lightness Races in Orbit
      Sep 6 at 10:46




      @SergiyKolodyazhnyy Somebody still came up with those :P
      – Lightness Races in Orbit
      Sep 6 at 10:46












      @LightnessRacesinOrbit Lol, OK, fair enough, I can agree with that. As a developer, one can choose what filenames to use. Some of my indicators use leading dot for config files in user's home directory, others - do not for files in ~/.config. But that choice also carries meaning and adheres to standards. A file ~/.config/.mything would be unconventional and confusing to users and be a sign of bad practice to other developers.
      – Sergiy Kolodyazhnyy
      Sep 6 at 12:42




      @LightnessRacesinOrbit Lol, OK, fair enough, I can agree with that. As a developer, one can choose what filenames to use. Some of my indicators use leading dot for config files in user's home directory, others - do not for files in ~/.config. But that choice also carries meaning and adheres to standards. A file ~/.config/.mything would be unconventional and confusing to users and be a sign of bad practice to other developers.
      – Sergiy Kolodyazhnyy
      Sep 6 at 12:42












      @SergiyKolodyazhnyy Yep I'm just being deliberately difficult about it to hammer home the point that . has no special meaning to the shell, contrary to the premise of the question
      – Lightness Races in Orbit
      Sep 6 at 12:43




      @SergiyKolodyazhnyy Yep I'm just being deliberately difficult about it to hammer home the point that . has no special meaning to the shell, contrary to the premise of the question
      – Lightness Races in Orbit
      Sep 6 at 12:43










      up vote
      4
      down vote













      The leading dot in file or directory names doesn't carry any particular significance, as far as Linux itself is concerned. However, certain utilities (such as ls or Nautilus file manager) consider such filenames as "hidden", that is they ignore them in their output, and will only show them if you provide a specific option.



      In reality, this originated with what technically can be considered a bug. Rob Pike, one of the original people who worked on UNIX team recounts (source):




      Long ago, as the design of the Unix file system was being worked out, the entries . and .. appeared, to make navigation easier. I'm not sure but I believe .. went in during the Version 2 rewrite, when the file system became hierarchical (it had a very different structure early on). When one typed ls, however, these files appeared, so either Ken or Dennis added a simple test to the program. It was in assembler then, but the code in question was equivalent to something like this:



       if (name[0] == '.') continue;


      This statement was a little shorter than what it should have been, which is



       if (strcmp(name, ".") == 0 || strcmp(name, "..") == 0) continue;


      but hey, it was easy.



      Two things resulted.



      First, a bad precedent was set. A lot of other lazy programmers introduced bugs by making the same simplification. Actual files beginning with periods are often skipped when they should be counted.



      Second, and much worse, the idea of a "hidden" or "dot" file was created. As a consequence, more lazy programmers started dropping files into everyone's home directory. I don't have all that much stuff installed on the machine I'm using to type this, but my home directory has about a hundred dot files and I don't even know what most of them are or whether they're still needed. Every file name evaluation that goes through my home directory is slowed down by this accumulated sludge.



      I'm pretty sure the concept of a hidden file was an unintended consequence. It was certainly a mistake.




      Nowadays, this sort of became a convention to call them "hidden" even though their contents are not hidden at all. A real hidden, or anonymous file/anonymous inode, would be implemented via opening file and holding its file descriptor open, but unlinking it from the directory, which makes the data itself to be accessible only to the program that is holding that file, and its child processes (preferably forked after unlinking the file), since child processes inherit file descriptors. In fact, this is how bash implements here-docs.



      Very different story is when filename is itself a dot . or .., which actually have a bit of history behind them, and I suggest you read Why is the current directory in the ls command identified as linked to itself?






      share|improve this answer


























        up vote
        4
        down vote













        The leading dot in file or directory names doesn't carry any particular significance, as far as Linux itself is concerned. However, certain utilities (such as ls or Nautilus file manager) consider such filenames as "hidden", that is they ignore them in their output, and will only show them if you provide a specific option.



        In reality, this originated with what technically can be considered a bug. Rob Pike, one of the original people who worked on UNIX team recounts (source):




        Long ago, as the design of the Unix file system was being worked out, the entries . and .. appeared, to make navigation easier. I'm not sure but I believe .. went in during the Version 2 rewrite, when the file system became hierarchical (it had a very different structure early on). When one typed ls, however, these files appeared, so either Ken or Dennis added a simple test to the program. It was in assembler then, but the code in question was equivalent to something like this:



         if (name[0] == '.') continue;


        This statement was a little shorter than what it should have been, which is



         if (strcmp(name, ".") == 0 || strcmp(name, "..") == 0) continue;


        but hey, it was easy.



        Two things resulted.



        First, a bad precedent was set. A lot of other lazy programmers introduced bugs by making the same simplification. Actual files beginning with periods are often skipped when they should be counted.



        Second, and much worse, the idea of a "hidden" or "dot" file was created. As a consequence, more lazy programmers started dropping files into everyone's home directory. I don't have all that much stuff installed on the machine I'm using to type this, but my home directory has about a hundred dot files and I don't even know what most of them are or whether they're still needed. Every file name evaluation that goes through my home directory is slowed down by this accumulated sludge.



        I'm pretty sure the concept of a hidden file was an unintended consequence. It was certainly a mistake.




        Nowadays, this sort of became a convention to call them "hidden" even though their contents are not hidden at all. A real hidden, or anonymous file/anonymous inode, would be implemented via opening file and holding its file descriptor open, but unlinking it from the directory, which makes the data itself to be accessible only to the program that is holding that file, and its child processes (preferably forked after unlinking the file), since child processes inherit file descriptors. In fact, this is how bash implements here-docs.



        Very different story is when filename is itself a dot . or .., which actually have a bit of history behind them, and I suggest you read Why is the current directory in the ls command identified as linked to itself?






        share|improve this answer
























          up vote
          4
          down vote










          up vote
          4
          down vote









          The leading dot in file or directory names doesn't carry any particular significance, as far as Linux itself is concerned. However, certain utilities (such as ls or Nautilus file manager) consider such filenames as "hidden", that is they ignore them in their output, and will only show them if you provide a specific option.



          In reality, this originated with what technically can be considered a bug. Rob Pike, one of the original people who worked on UNIX team recounts (source):




          Long ago, as the design of the Unix file system was being worked out, the entries . and .. appeared, to make navigation easier. I'm not sure but I believe .. went in during the Version 2 rewrite, when the file system became hierarchical (it had a very different structure early on). When one typed ls, however, these files appeared, so either Ken or Dennis added a simple test to the program. It was in assembler then, but the code in question was equivalent to something like this:



           if (name[0] == '.') continue;


          This statement was a little shorter than what it should have been, which is



           if (strcmp(name, ".") == 0 || strcmp(name, "..") == 0) continue;


          but hey, it was easy.



          Two things resulted.



          First, a bad precedent was set. A lot of other lazy programmers introduced bugs by making the same simplification. Actual files beginning with periods are often skipped when they should be counted.



          Second, and much worse, the idea of a "hidden" or "dot" file was created. As a consequence, more lazy programmers started dropping files into everyone's home directory. I don't have all that much stuff installed on the machine I'm using to type this, but my home directory has about a hundred dot files and I don't even know what most of them are or whether they're still needed. Every file name evaluation that goes through my home directory is slowed down by this accumulated sludge.



          I'm pretty sure the concept of a hidden file was an unintended consequence. It was certainly a mistake.




          Nowadays, this sort of became a convention to call them "hidden" even though their contents are not hidden at all. A real hidden, or anonymous file/anonymous inode, would be implemented via opening file and holding its file descriptor open, but unlinking it from the directory, which makes the data itself to be accessible only to the program that is holding that file, and its child processes (preferably forked after unlinking the file), since child processes inherit file descriptors. In fact, this is how bash implements here-docs.



          Very different story is when filename is itself a dot . or .., which actually have a bit of history behind them, and I suggest you read Why is the current directory in the ls command identified as linked to itself?






          share|improve this answer














          The leading dot in file or directory names doesn't carry any particular significance, as far as Linux itself is concerned. However, certain utilities (such as ls or Nautilus file manager) consider such filenames as "hidden", that is they ignore them in their output, and will only show them if you provide a specific option.



          In reality, this originated with what technically can be considered a bug. Rob Pike, one of the original people who worked on UNIX team recounts (source):




          Long ago, as the design of the Unix file system was being worked out, the entries . and .. appeared, to make navigation easier. I'm not sure but I believe .. went in during the Version 2 rewrite, when the file system became hierarchical (it had a very different structure early on). When one typed ls, however, these files appeared, so either Ken or Dennis added a simple test to the program. It was in assembler then, but the code in question was equivalent to something like this:



           if (name[0] == '.') continue;


          This statement was a little shorter than what it should have been, which is



           if (strcmp(name, ".") == 0 || strcmp(name, "..") == 0) continue;


          but hey, it was easy.



          Two things resulted.



          First, a bad precedent was set. A lot of other lazy programmers introduced bugs by making the same simplification. Actual files beginning with periods are often skipped when they should be counted.



          Second, and much worse, the idea of a "hidden" or "dot" file was created. As a consequence, more lazy programmers started dropping files into everyone's home directory. I don't have all that much stuff installed on the machine I'm using to type this, but my home directory has about a hundred dot files and I don't even know what most of them are or whether they're still needed. Every file name evaluation that goes through my home directory is slowed down by this accumulated sludge.



          I'm pretty sure the concept of a hidden file was an unintended consequence. It was certainly a mistake.




          Nowadays, this sort of became a convention to call them "hidden" even though their contents are not hidden at all. A real hidden, or anonymous file/anonymous inode, would be implemented via opening file and holding its file descriptor open, but unlinking it from the directory, which makes the data itself to be accessible only to the program that is holding that file, and its child processes (preferably forked after unlinking the file), since child processes inherit file descriptors. In fact, this is how bash implements here-docs.



          Very different story is when filename is itself a dot . or .., which actually have a bit of history behind them, and I suggest you read Why is the current directory in the ls command identified as linked to itself?







          share|improve this answer














          share|improve this answer



          share|improve this answer








          edited Sep 10 at 7:12









          dessert

          20k55795




          20k55795










          answered Sep 10 at 3:09









          Sergiy Kolodyazhnyy

          65.7k9134287




          65.7k9134287




















              up vote
              3
              down vote













              A dot at the beginning of a filename hides the file in common file managers and for common shell programs.



              The reason is historical, when ls hid the special directories . and .. by hiding everything which starts with a period. Then people used filenames starting with a period to hide files, so they are only listed with ls -a, for example to make configuration files invisible which are not needed in the ls output usually.



              So the dot in chmod -R 421 .gimp is not a modifier of the command, but a part of the actual directory name.






              share|improve this answer
























                up vote
                3
                down vote













                A dot at the beginning of a filename hides the file in common file managers and for common shell programs.



                The reason is historical, when ls hid the special directories . and .. by hiding everything which starts with a period. Then people used filenames starting with a period to hide files, so they are only listed with ls -a, for example to make configuration files invisible which are not needed in the ls output usually.



                So the dot in chmod -R 421 .gimp is not a modifier of the command, but a part of the actual directory name.






                share|improve this answer






















                  up vote
                  3
                  down vote










                  up vote
                  3
                  down vote









                  A dot at the beginning of a filename hides the file in common file managers and for common shell programs.



                  The reason is historical, when ls hid the special directories . and .. by hiding everything which starts with a period. Then people used filenames starting with a period to hide files, so they are only listed with ls -a, for example to make configuration files invisible which are not needed in the ls output usually.



                  So the dot in chmod -R 421 .gimp is not a modifier of the command, but a part of the actual directory name.






                  share|improve this answer












                  A dot at the beginning of a filename hides the file in common file managers and for common shell programs.



                  The reason is historical, when ls hid the special directories . and .. by hiding everything which starts with a period. Then people used filenames starting with a period to hide files, so they are only listed with ls -a, for example to make configuration files invisible which are not needed in the ls output usually.



                  So the dot in chmod -R 421 .gimp is not a modifier of the command, but a part of the actual directory name.







                  share|improve this answer












                  share|improve this answer



                  share|improve this answer










                  answered Sep 6 at 15:18









                  allo

                  4207




                  4207



























                       

                      draft saved


                      draft discarded















































                       


                      draft saved


                      draft discarded














                      StackExchange.ready(
                      function ()
                      StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f1072377%2fwhat-does-the-period-mean-at-the-start-of-a-filename-in-a-terminal-command%23new-answer', 'question_page');

                      );

                      Post as a guest













































































                      Popular posts from this blog

                      How to check contact read email or not when send email to Individual?

                      Bahrain

                      Postfix configuration issue with fips on centos 7; mailgun relay