[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: .text or .txt

On Thu, 12 Apr 2001 23:34:19 -0700
Seth Arnold <sarnold@willamette.edu> wrote:

> * Alexander Hvostov <vulture@aoi.dyndns.org> [010412 23:03]:
> > Filesystem-level strong typing is bad? Please explain! This is something I
> > probably ought to know.
> Disclaimer: I've only seen Apple's implementation. Perhaps someone
> else's implementation would be worthwhile. The gist is, the number of
> times when I have tried to edit a .txt file, or .html file, or .java
> file on a macintosh (where it was generated on another machine)
> successfully is *very* low. Simpletext refuses to edit the file, because
> it wasn't generated with simpletext, or the machine drags in a
> thirty-pound editor (e.g., symantec cafe) when a much smaller one would
> suffice (simpletext), or files do not get transferred properly to other
> operating systems (as a result of the resource fork).
> If the system could be easily over-ridden, I may very well like it. But,
> without using resedit (is that it?) I don't know of any ways of getting
> Simpletext to edit an .html file generated on another machine using some
> purpose-specific application.
> The end result -- I would like my applications to do as I tell them. If
> I know the file is a text file, it sure would be nice for Word or
> SimpleText or IE or netscape to give a good shot at rendering the file.
> If I know the file is a word file, or rtf file, or somehow ought to be
> compatible with word, I want word to give a shot at converting the file,
> rather than the OS getting in my way.
> If *everyone* used macs, and everyone had the same applications, I doubt
> I would ever notice any problems. But not many people use macs and it is
> even less likely that everyone has the same applications.
> Features of unix boxes I *love* -- vi will edit anything. strings will
> show me all the text in a file. No filesystem pretending to know what is
> best for me. :)

My point of view is that the filesystem's strong typing should be _advisory_,
not _mandatory_ -- that is, programs can query the file type if they're not
sure what to do with a file, and can take several different actions with it
depending on its type. The mime-support package could take advantage of this
by simply looking up the file type, rather than having to use magic numbers
and whatnot to try to "guess" the file type, which is, despite how well it
works, a brutal hack which I definitely do not favor as a replacement for
filesystem-level strong typing.

Storing these file types on the filesystem would be especially useful for
file managers like Nautilus, Konqueror, mime-support, and so on. These
programs could simply check the file type on the filesystem, rather than
using file(1) magic to guess the file type. Despite how well file(1) works,
it is a non-deterministic hack, and the signatures of various file formats
do sometimes collide with each other, making them difficult (if not
impossible) to tell apart.

Of course, this being Unix, there would almost certainly be a way to manually
change the file type; something like this:

  $ chtype somefile.html text/plain
  $ edit somefile.html
   [ `edit' starts your favorite editor... ]


  $ edit text/plain:somefile.html
   [ `edit' starts your favorite editor... ]

...depending on whether you want to change the file type temporarily or
permanently. The latter example is actually how you would do it now, to override
mime-support's file(1) magic stuff.

The point about editors refusing to open foreign file formats is probably not
an issue here, since Unix editors don't generally care about the file type.

My conclusion is that your troubles with filesystem-level strong typing are, in
fact, a poor implementation, rather than a poor concept. Actually, the more I
think about the concept, the more I like it...



Reply to: