Very Computer

I was curious if there is any standard method for retrieving file
associations in Linux. How do file associations work in KDE and any
pointers on where I can get more information for non-KDE linux installs.
Thanks.

Hi,

It's not totally clear what you mean by retrieving the file associations,
but that could be an interesting discussion....

Linux doesn't depend on file extensions to denote a file's type, but many
programs (like KDE) can use them to help with executable selection, and of
course with graphical display of types in a GUI.  That's why many
executables don't have any extension - it's "bash", not "bash.exe", for
instance.  Similarly, a tar file does not need the extension .tar to make
it work with the tar program. It's used as a convenient mechansim for
hinting at what a file might be.

Excutables look at the header info in a file to figure out what it is and
if they can use it. There is a a program called "file" which will look at
an otherwise anonymous file and tell you what it is. For instance :-

Quote:>>file knode

knode: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically
linked (uses shared libs), stripped

Tells you that knode is an ELF executable program for i386 based Linux,
amongst other data.  I believe the method for associating file extensions
with executables is different from KDE to Gnome and probably for other
window managers.  There may be a standard, but I'm not aware of it.

Maybe others out there can comment more fully.

HTH,

Paul

We can easily go beyond that; filesystems on Linux don't /have/ "file
extensions," except for those FSes that emulate those used on other
systems.  For instance, the MS-DOS filesystem has "extensions."  But
ext2, ext3, and the other "native" filesystems certainly do NOT.

When the concept isn't even implemented, it seems improbable that it
would make any sense for Linux to depend on it, no?

The same is true for NetBSD, OpenBSD, FreeBSD, and many of the other
systems on which KDE is supported.

Quote:> Excutables look at the header info in a file to figure out what it
> is and if they can use it. There is a a program called "file" which
> will look at an otherwise anonymous file and tell you what it
> is. For instance :-

>>>file knode
> knode: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically
> linked (uses shared libs), stripped

> Tells you that knode is an ELF executable program for i386 based Linux,
> amongst other data.  I believe the method for associating file extensions
> with executables is different from KDE to Gnome and probably for other
> window managers.  There may be a standard, but I'm not aware of it.

> Maybe others out there can comment more fully.

There can't conceivably be a standard for the support of something
("extensions") that doesn't exist.
--

http://cbbrowne.com/info/emacs.html
"Imagine a law so stupid that civil obedience becomes an efficient way
to fighting it" --Per Abrahamsen on the DMCA

Hi,

You make a very good point.  However, I thought that the file extensions
part of DOS or windows was not to do with the file ystem as such, but just
how the OS deals with finding out what files are or contain.  In other
words, the extensions are necessary to help a simple minded OS, but are not
part of the file system requirements.  Am I wrong?  Educate me!

Regards,

Paul

Quote:> You make a very good point.  However, I thought that the file extensions
> part of DOS or windows was not to do with the file ystem as such, but just
> how the OS deals with finding out what files are or contain.  In other
> words, the extensions are necessary to help a simple minded OS, but are not
> part of the file system requirements.  Am I wrong?  Educate me!

File "extensions" have been implemented as part of the filesystems on
many OSes, NOT all of which are fairly characterizable as "simple
minded."

OSes supporting "extensions" include:
 - MVS
 - OS/9
 - VMS
 - VM/CMS
 - CP/M
 - MacOS
 - Probably Multics (on which Unix was based)
 - Symbolics

If anything, it would be fairer to characterize the /lack/ of
extensions as being "simple-minded;" it indicates a lack of "file
typing" that might be criticized much the way manifest typing is
criticized in Lisp-like languages.

"Extensions" /have/ to be supported in the OS in order to be used as
such; as a contrary example, commonly seen on Unix, consider the file
named "something.tar.gz"

Since Unix doesn't have "extensions," the ".tar.gz" part is NOT an
"extension."  The presence of /two/ suffixes shows that something more
complex is happening.  It's a tarball that is being compressed.
Similarly, I'd expect "install.sh.gz" to be a compressed shell script,
based on the suffix.

The problem on MS-DOS and its descendents is that while it has
extensions, it does not really support intelligent use thereof, and
the environments built on top of it have gotten the worst of the
possible worlds:

 - As on Unix, the actual /use/ of extensions is quite anarchic;

 - But since they are there, people make the mistake of thinking it's
   NOT an anarchy, and so we get apps that assume that extensions
   are meaningful;

 - Then comes the even worse thing, as the schemes used to allow
   having spaces and such in filenames make it into more of an
   "anarchy," where viruses get named things like "my-picture.mp3.pif"
   so as to fool both applications and people into thinking they are
   music files whilst actually being executable content.  And Windows
   often gets even more confused than you'd expect in that there seem
   to be two "extensions" when the OS only supports one...
--

http://cbbrowne.com/info/sap.html
"A good system can't have a weak command language."  -- Alan Perlis
[This explains why MS-DOS and Windows can't possibly be good
systems...]