Linux filenames

[Yohhan]

What is the Linux filenaming convention? I see file names like: file.filename.tar.gz

What do all of the seperating periods mean?

I'm coming over from windows, so I'm used to the filename.ext. How do I tell which linux files are executable, etc? Also, I read somewhere that a file such as: ".filename" is considered hidden. How do I show hidden files?

I'm using Redhat 7.2 distro.

Thanks ahead for any help.

 

[n0cmonkey]

"ls -a" will show hidden files.

.tar is a "tape archive", aka a collection of files.
.gz is a gnu-zipped file (compressed).

Executable files should be in "bin" directories, aka /usr/bin, /bin, /usr/sbin/, /sbin, /usr/local/bin, /usr/local/sbin, etc. To find out what most files are, try "file name.of.file". You can also read the man page for ls. Pay attention to the -F option, its one I alias ls to use instead of the default ls behavior.

 

[FUBAR]

Just for added confusion, there is another file that is extremely similar to the one you are asking about. .tar.gz is a gzipped tar(think of a zipfile with 0% compression) file, which you could read to mean that it was tarred then gzipped seperately. You can go the other way too... gunzip filename.tar.gz, then tar -xvf filename.tar

You can also see a .tgz which by most conventions is a gzipped tar file made in one step with the -z option to tar (i.e. tar -czvf filename.tgz dir_to_tar)

Other than that type of thing (including bz2 (bzip2) and other compressions) and pictures, extensions are generally unimportant. A .conf file could be thought of as being similar to an ini file, and there are a few other ones out there. Whether or not a file is executable is also a factor of the permissions on it. Do an ls -alF on something like /bin and you will see permissions like so:

[pgienger@isis pgienger]$ ls -alF /bin
total 6296
drwxr-xr-x 2 root root 4096 May 9 17:15 ./
drwxr-xr-x 22 root root 4096 May 10 00:29 ../
-rwxr-xr-x 1 root root 2704 Apr 1 17:26 arch*
-rwxr-xr-x 1 root root 94364 Jun 24 2001 ash*
-rwxr-xr-x 1 root root 472492 Jun 24 2001 ash.static*
-rwxr-xr-x 1 root root 10312 Feb 26 04:20 aumix-minimal*


The x in the first part there means it's executable by the owner (root) the group (also root in this case) and the world... look for a description of the permissions structure elsewhere 😉. But also note that any files can have the executable bit set, like text files. if all else fails, try and run something, just be careful not to do it as root if in doubt.. that can cause problems, and security issues.

 

[n0cmonkey]

Originally posted by: FUBAR
Just for added confusion, there is another file that is extremely similar to the one you are asking about. .tar.gz is a gzipped tar(think of a zipfile with 0% compression)

A gzipped tarfile has compression, a tarfile has none. I know thats what you meant, I just had to read it twice to make sure. 🙂

file, which you could read to mean that it was tarred then gzipped seperately. You can go the other way too... gunzip filename.tar.gz, then tar -xvf filename.tar

You can also see a .tgz which by most conventions is a gzipped tar file made in one step with the -z option to tar (i.e. tar -czvf filename.tgz dir_to_tar)

You can gunzip a .tgz seperately too.

Other than that type of thing (including bz2 (bzip2) and other compressions) and pictures, extensions are generally unimportant. A .conf file could be thought of as being similar to an ini file, and there are a few other ones out there. Whether or not a file is executable is also a factor of the permissions on it. Do an ls -alF on something like /bin and you will see permissions like so:

.cfg is also a common extension for config files.

 

[FUBAR]

Thanks... I often forget to pipe the output from my brain throgh the readability and understandability filter before sending it to stdout :-D

 

[n0cmonkey]

Originally posted by: FUBAR
Thanks... I often forget to pipe the output from my brain throgh the readability and understandability filter before sending it to stdout :-D

I have problems with that too, but the elitist filter is on by default, its tough to route around it. I *should* send in a bug report to the BSD developers telling them how I got through, but I dont think its all that necessary.