Linux determines weither or not a file is executable by the file permissions.
For instance
~ >: ls -l /bin/ls
-rwxr-xr-x 1 root root 75948 Jul 16 06:37 /bin/ls
ls is executable. The file permission are simple, 3 sets of 3 types of permissions. Read, write, execute. Then you have a different set of permissions for each set of users, "user" (owner), "group", and "other"(world)
rwx = read write execute
r-x = read nowrite execute.
--- = noread nowrite noexecute.
First group of rwx is for the owner, the second set is for people belonging to that particular file's group, and the third is for everybody else.
With this particular file 'root' is the owner, and 'root' is also the name of the group...
In the following file is a "device" file that represents hardware or software resources. This one represents the sound card. (you can even pipe output from another command or 'cat' text into it like a regular file, but don't have your volume turned up!)
~ >: ls -l /dev/dsp0
crwxrwxrwx 1 root audio 14, 3 Apr 19 2004 /dev/dsp0
If you want to know more about the file you can always use the "file" command...
~ >: file /bin/ls
/bin/ls: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.2.0, dynamically linked (uses shared libs), stripped
~ >: file /dev/dsp0
/dev/dsp0: character special (14/3)
(14/3 refer to the major and minor device codes that hook into the kernel for that particular resource.. don't need to worry about it. Random information.)
~ >: file /etc/fstab
/etc/fstab: ASCII text
~ >: file /etc
/etc: directory
That sort of thing.
On your desktop when you double click on something it first tries to figure out what you want to do with the file. Most of the time you don't execute files that way, what happens is that the file manager determines the "mime" type for the file, then executes a application in a attempt to handle it. Generally Linux ingores filenames... you can rename a .mp3 file to a .doc file and sometimes it will still work, but if you explicitely run the file it will work at the command line, however sometimes in the GUI portion the filename is used as part of the mime hinting and it won't always be confused. For instance if I have a mp3 file with a .doc extent
For example:
~ >: cp TyranosaurusinGMajor.mp3 TyranosaurusinGMajor.txt
~ >: file TyranosaurusinGMajor.*
TyranosaurusinGMajor.mp3: MP3 file with ID3 version 2.3.0 tag
TyranosaurusinGMajor.txt: MP3 file with ID3 version 2.3.0 tag
~ >: mpg321 TyranosaurusinGMajor.txt
High Performance MPEG 1.0/2.0/2.5 Audio Player for Layer 1, 2, and 3.
Version 0.59q (2002/03/23). Written and copyrights by Joe Drew.
Uses code from various people. See 'README' for more!
THIS SOFTWARE COMES W (snip, it played correctly)
When I double click on the .mp3 in the GUI it plays fine, but when I do that to the .txt file I get:
The filename "TyranosaurusinGMajor.txt" indicates that this file is of type "Plain text document". The contents of the file indicate that the file is of type "MP3 audio". If you open this file, the file might present a security risk to your system.
Do not open the file unless you created the file yourself, or received the file from a trusted source. To open the file, rename the file to the correct extension for "MP3 audio", then open the file normally. Alternatively, use the Open With menu to choose a specific application for the file.
If I right click it it will give me the choices of using programs that will handle it as a text file AND programs that will handle it as a mp3.
Note that this is in Debian Unstable with Gnome 2.6, KDE will be different, and Gnome 2.8 should offer better mime detection. If I set permissions to execute it still gives me the same error. I figure this sort of thing is a bit more intelligent then what is offered with Windows. If I make a proper executable, like a bash script (the computer identifies it as a bash script by adding the #! /bin/bash as the first line of the file) then it will run well.
So if you download a RPM package (redhat package manager packages) and then double click on it, sometimes it won't do anything, but other times (it depends on how the distro is setup) it'll run some gui program that is designed to install the package for you. RPM packages are non-executable packages...
Other installers (like Nvidia's install file) are sh scripts, too... They just have a compressed file imbedded inside them that contains the binary driver + the source code needed to make it work with your kernel.
Different distros use different file managers. RPM-based distros like Redhat/Fedora/Mandrake/Suse share a common anscestry with Redhat 6 series OS'es, so generally the work the same.
Debian uses .deb files, but it's rare that you actually download them, you generally use apt-get to download them and install them automaticly.
Then there are instances were you just download tarballs that contain source code and you compile and install them on your own using configure scripts and MAKE files. This automates the proccess of compiling and installing programs from the source code.
Generally you go:
tar zxfv programname.tar.gz
cd programname
./configure
make
make install
(but there are a lot of variations and no set rules, read the readme files, and for .bz2 files you go "tar jxfv" instead of "tar zxfv")
Most programs get installed into the /usr/ directory most of the time. Each type of file has it's own specific place that belongs in the directory system. Executable binaries and scripts get stuck in a directory like /bin/ /usr/bin /usr/local/bin. Binarys/executables intended just to be used by root end up in similar sbin/ directories.
Then as you know binaries don't exist in a vaccuum. You have library files (like .dll files in linux.). These get stuck in lib/ directories, extra information such as icons and such get stuck in corrisponding share/ directories. Sometimes code that are related to programs get stuck in include/ directories, sometimes kept around to make compiling programs easier and stuff like that.
Then distro provided programs (generally ones you install using rpm file packages) get stuck in /usr/ directory. Files that get installed by 3rd party installers or compiled from source generally get installed in /usr/local, so that when you upgrade packages or do system management the OS knows to leave stuff in /usr/local alone and let the admin handle it. Then you have others for convenience like /usr/local/games and such like that.
Just open up the terminal and begin cd'ing around everywere checking out files, file types, and their purposes, after a little while it all begins to make sense.
Usually in Linux you can tell the purpose and sometimes origin of the file, not by it's file extensions (although that helps), but by it's location in the file directory system. The command line rpm tools have switches and options that will tell you what file came from what package if you need to know.
See some of the guides linked to in my sig. Most of this info isnt' realy nessicary to operating the OS, but it is for understanding the OS. Check out "Introduction to Linux - A Hands on Guide" for starters. It's designed more for the administrator/power user type people, more so then the the casual user or end user.
