Hello Neil!

Replying to a message of Neil Heller to William McBrine:

 NH> 
 WM>> You can of course override the PATH searching by specifying a full
 WM>> pathname  explicitly, as you would in DOS. To run an executable from
 WM>> the current  directory, the simplest method is therefore:

 WM>>  ./filename

 WM>> That's the usual way for something that you're just testing, and
 WM>> haven't  yet installed somewhere in the PATH.

 NH> That's exactly what I was looking for.

 NH> One question, though.  Is there any presumed extension (like
"EXE", 
 NH> "COM", etc.) that's presumed and doesn't have to be typed when
 NH> executing  the program?  If not, need the full filename be typed at
 NH> the command  line every time when launching an app?

No.  Unix executables generally do not have extentions.  Using EXE or COM
or BAT or other such nonsense was a Microsoft hack when they removed the
extra attributes that unix files get.

DOS (and thus Windows and OS/2) have Read, Directory, Hidden, and System
attributes (I think that's all of them).  Nothing specifying whether a file
is executable or not.  So they use the extention to figure it out.

Unix has a large bit-flag, which is commonly shown as:

-rwxrwxrwx

The first character is any "special" flag - such as this file is
a symbolic link, a raw character device, other devices, or even a
directory.  The next three are permissions for the owner of the file, then
the group that the file belongs to, then everyone else.  Each one is Read,
Write, and Execute.

Thus, if you are logged in as the owner of the file, then the first triad
is what affects you.  If you belong to the group that the file is in, then
the second triad concerns you.  Finally, if you are neither of the above,
then you get access according to the last triad.

Of course, it gets a lot more complicated than that.

* If it's a directory, 'x' means "can cd into this directory",
'r' means "can ls in this directory", and 'w' means "can
create files in this directory".

* If the x is really an 'S', it means "setuid" or
"setgid" if it's in the user (owner) or group triads,
respectively.

* If the x is really an 's', it is a combination of 'S' and 'x'.

* If the x is really a 't', it is the "sticky" bit which has
certain other connotations that I've not really got straight enough in my
head to explain it.  This only occurs in the "other" triad.

Setuid and setgid flags mean that no matter who runs the file (assuming
they have such permissions), the program will have the ability to switch to
that user and/or group, depending on which flag(s) is(are) set.

Thus, "foo" is just a file, but if it has the execute bit set,
then it's an executable file.  The kernel will look at the first two or
more bytes to determine what type of executable file it is.  If it starts
with "#!", then it reads the rest of that line, and passes the
file as a parameter to the program listed there.  Otherwise, if it is the
magic number appropriate for executables on this platform, then it calls
the loader to load and start the program executing.

Certain conventions exist for executable source code (such as shell scripts
or perl scripts), but if the user is expected to call them interactively
(at the shell prompt), then the script usually has no extention.  Even with
these conventions, the shell does not care about them, and will rely on the
first line pointing out what it is.  Thus a perl script with extention
".sh" will still work, even though the casual observer will
assume that it's a shell script due to the extention.

Darin

---