Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

I was wondering what is the naming convention for files in Unix?

I am not sure about this, but I think there is perhaps a universal naming convention that one should follow?

For example, I want to name a file say: backup with part 2 and random

Should I do it like this:

backup_part2_random

OR

backup-part2-random

OR

backup.part2.random

I hope the question is clear. Basically, I want to choose a format that conforms to the Unix philosophy.

share|improve this question
    
As a general comment re the "conventions" ... I've just read all the answers so far, and it struck me how odd it is that there is almost an obscession with using only one case in a system where (I think) one of its strengths is the ability to meaningfully use both cases... Was the original design (case-sensitive) an over design)... just musing –  Peter.O Feb 14 '11 at 12:34
    
my opinion: there is no convention. file names are just strings. pick your favourite style. –  glenn jackman Feb 14 '11 at 13:24
add comment

10 Answers

Far more important that a particular convention is being consistent. Pick a style, and stick with it.

share|improve this answer
    
I'd replace "standard" with "style", otherwise a +1 –  Jürgen A. Erhard Feb 14 '11 at 12:45
    
@jae: yep, that's a better word. –  David Oneill Feb 14 '11 at 14:34
add comment

. is used to separate a filetype extension, e.g. foo.txt.

- or _ is used to separate logical words, e.g. my-big-file.txt or sometimes my_big_file.txt. - is better because you don't have to press the Shift key, others prefer _ because it looks more like a space.

So if I understand your example, backup-part2-random or backup_part2_random would be closest to the normal Unix convention.


CamelCase is normally not used on Linux/Unix systems. Have a look at file names in /bin and /usr/bin. CamelCase is the exception rather than the rule on Unix and Linux systems.

(NetworkManager is the only example I can think of that uses CamelCase, and it was written by a Mac developer. Many have complained about this choice of name. On Ubuntu, they have actually renamed the script to network-manager.)

For example, on /usr/bin on my system:

$ ls -d [A-Z]* | wc -w    # files starting with a capital
6
$ ls -d *_* | wc -w       # files containing an underscore
178
$ ls -d *-* | wc -w       # files containing a minus/dash
409

and even then, none of the files starting with a capital uses CamelCase:

$ ls -d [A-Z]*
GET  HEAD  POST  X11  Xvnc  Xvnc4
share|improve this answer
    
Should be the top answer, since it gives all the information required to make a decision. Thanks. –  Olegs Jeremejevs Aug 12 '12 at 17:02
add comment

In unix filename is just a string, unlike DOS, where filename was composed from name and extension. So any of given filenames is completely acceptable.

But many programs still use file suffixes beginning with dot to distinguish different file types, i.e. Apache Web Server uses suffixes to set correct MIME type in answer headers.

share|improve this answer
3  
While gelraen is 100% correct: Unix/Linux as such does not care about file extensions, modern flavours of Linux do care in so far as some shell extensions provide special identification (colours or otherwise) of certain file types and file managers provide automatic associations with programs. But just as important is for the human user to know which file is what type. To that end it is convenient to stick to a standard scheme not just consistent for yourself but with others. In this respect things should not be overly different than MS Windows (or MIME). –  asoundmove Feb 13 '11 at 21:24
    
That said sometimes several different extension styles can match the same purpose. Thus .tar.gz is equivalent to .tgz, .tar.bz2 = .tbz, .ps.gz is often shortened as .ps (confusingly) and I'm sure there are many more. –  asoundmove Feb 13 '11 at 21:28
    
@asoundmove .ps.gz means it's a compressed .ps file. Just like .tar.gz means compressed .tar file. –  jonescb Feb 14 '11 at 15:42
    
@jonescb, yes of course. My point about it being confusing is that when I see .ps I expect a non compressed file (which I should be able to cat or less), but often .ps files are compressed and should in fact be .ps.gz for clarity (as they require zcat or zless for source code viewing). Some people decided to just suffix compressed PostScript files with .ps anyway because some common ps viewers actually don't mind whether they are compressed or not. –  asoundmove Feb 14 '11 at 23:03
add comment

Characters you should not use in filenames:

| ; , ! @ # $ ( ) < > / \ " ' ` ~ { } [ ] = + & ^

Character delimiters you should use to make names easier to read:

_ - . :

(In some cases ":" has special meaning though)

share|improve this answer
1  
Of course, you can't even use "/" in filenames. Everything else is possible. And if you want to make it hard to access, even useful ;-) –  Jürgen A. Erhard Feb 14 '11 at 12:48
    
The list is actually a lot longer, including control and non-ASCII characters. Yes, you can have a backspace as part of a *nix file name. –  l0b0 Jun 20 '11 at 12:13
    
More to the point, most *nix systems only disallow two specific characters in file names: the / path separator, and the \0 (ASCII zero) string terminator. –  Michael Kjörling Jun 26 '13 at 21:45
add comment

My take on Unix/Linux filename conventions:

  • Unix/Linux filesystems don't inherently support the notion of an extension. The concept of a file extension completely exists as something supported by utilities such as cp, ls, or the shell you are using. I believe it is this way on NTFS as well, but I could be wrong.

  • Executables, including shell scripts, usually never have any type of extension. Scripts will have a hashbang line (i.e. #!/bin/bash) that identifies what program should interpret it.

  • Any executable that is two letters long is super important. So don't name your executables two-letter filenames. Any file in /etc ending in tab is also super important, such as fstab, mtab, inittab.
  • Sometimes .d is appended to directory names, particularly in /etc, but this isn't widespread (UPDATE: http://serverfault.com/questions/240181/what-does-the-suffix-d-mean-in-linux)
  • rc is widely used for configuration scripts or files, either prepending (e.g., rc.local) or suffixing (.vimrc)
  • The Unix/Linux community has never had a three-character limit on extensions and frowns upon shortening well know extensions to fit. For example, don't use .htm at the end of HTML files on Unix/Linux, use .html.
  • In a set of files, a filename is sometimes capitalized, or in all caps, so it appears at the head of a directory listing. The classic example is Makefile in source packages. Only do this for stuff like README.
  • ~ is used to identify a backup file or a directory, as in important_stuff~, or /etc~. Many shells will expand a lone ~ to $HOME.
  • Library files almost always begin with lib. Exception is zlib and probably a few others.
  • Scripts that are called by inetd sometimes are tagged with a leading in., such as in.tftpd.
  • The ending z in vmlinuz means zipped, but I've never seen any other file named this way.
share|improve this answer
1  
I often see shell scripts with a .sh "extension" on them. I personally find it somewhat annoying, but I have to admit that I may be ignorant of some good reason for using the .sh. –  Dan Moulding Feb 14 '11 at 19:07
1  
A thing comes to mind that it's useful to emphasize the fact that it is a text-based script and not a binary. –  ultrasawblade Feb 14 '11 at 20:00
add comment

To add to what others have said, I'd just say that while accented letters and many special characters are legal in filenames they can cause issues in any of the following scenarios:

  • You share your filesystem with other computers, particularly with different operating systems;
  • You share files with others (and although email tends to be quite good with conversions, sometimes it just does not work);
  • You use shell scripts to automate some tasks (spaces are particularly problematic, though there are many ways to deal with them);
  • You use a file share from another computer.

...

share|improve this answer
add comment

Stick to alphanumeric filenames. Avoid spaces or replace spaces with underscores ( _ ). Limit punctuation in file names to periods (.), underscores ( _ ), and hyphens (-). Generally filenames are lowercase, but I use CamelCase when I have multiple words in the filename.

Use extensions which indicate the type of file. Programs do not need extensions as the execute bit is used to indicate programs, and the shells know how to run programs of various types. It is common but not required to (.sh) for shell scripts, and (.pl) for perl scripts. The Windows executable extensions .bat, .com, .scr, and .exe indicate Windows executables on Unix.

Pick a standard and stick to it. But it won't break things if you avoid it.

Hidden (or dot) files have names starting with a period. These normally don't show up in directory listings. Use 'ls -a' to include the dot files in the list.

share|improve this answer
    
CamelCase is an anti pattern on Unix. The OP was asking about conventions. –  Mikel Feb 13 '11 at 21:46
    
It's not "bad" versus "good". It's "this is how it's usually done". It's a convention the OP was asking for. The reason? It could be because Unix people don't like pressing Shift, it could be because old systems only had UPPERCASE, or for another reason. I'm not sure. –  Mikel Feb 14 '11 at 3:03
    
@Mikel I also program Java where CamelCase is a convention. Sometimes patterns and conventions conflict. –  BillThor Feb 14 '11 at 17:16
    
.scr is also a Windows executable extension. –  ultrasawblade Feb 25 '11 at 0:17
1  
@ultrasawblade Thanks, shows how often I script Windows. I tried to skip the rarer executable extensions like cmd, pif, vb*, wsh, and the rest of them. –  BillThor Feb 25 '11 at 19:37
add comment

I agree with David Oneill that you should just go with something.

But it is nice if the files is sortable in the same dir, so dont number 0..10 but number 00..10.

When using dates in names, go with a standard date format like ISO8601.

And dont be afraid to use multiple chars to separate logical parts in the name. If you use _ (that was 3 _), then you can simplify the regexps on filenames later on.

So your example could then be something like this:

backup_2011-06-19T114012___part002___random

Easy to read and easy to parse with scripts.

share|improve this answer
add comment

There is definitely a standard for Linux. If you look at the file names in any Linux system they are lower case with dashes: /usr/bin/ssh-keygen. This is specified in one of the Linux Standards Base documents that I cannot find right now. It is also specified by GNU which says to use underscores for variable names and dashes for file names.

share|improve this answer
add comment

To add to what everyone else has said:

1-Even though Linux doesn't care much about extensions, Windows does, so make sure any file you ever plan on giving anyone has the appropriate extension.

2-Camel caps seems to be the easiest to use scripts with, no special characters to worry about escape sequences.

share|improve this answer
3  
-1. CamelCase is NOT used on Linux. –  Mikel Feb 13 '11 at 21:50
    
Thank you, will remove. –  Yitzchak Feb 14 '11 at 0:04
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.