And pray tell, what header lines do you put at the beginning
of executable files?,
You just put some header lines that indicate that this file is an
executable file, and some information to distinguish it from
executable files for other hardware vendors' machines or even
different versions of the same vendor's systems.
For example, if SunOS 4.1.1 executables are not executable on SunOS
4.0.X systems, this information might come in handy when a 4.0.X
system remote-mounts a 4.1.1 filesystem.
(By the way, you would have to upgrade the kernel before you prepend
headers to executables.)
database files?,
You just name the database system. You might put "Oracle", together
with the version number. So an Oracle program, having been invoked by
the GUI, would be able to tell whether or not it could process this
file. Of course, Oracle may already include such information in its
files. The point is, however, that not all applications have
human-readable headers in their files. The human will find these
headers very useful if and when the GUI is not able to access the
corresponding program.
and other files containing inherently binary data?
There is nothing wrong with putting an ASCII header in front of
"inherently binary data". The computer certainly doesn't care. It's
all binary as far as the computer is concerned. However, the ASCII
header is very meaningful to humans, since we can establish some very
simple rules to map the first handful of bits to descriptive text on
the screen, or printer, or whatever.
Meta data (and codeset announcement is meta data) belongs in the inode
on Unix systems.
I cannot bring myself to disagree with you strongly here. Separating
the data itself from the stuff that describes it, has a certain
appeal. If a vendor can upgrade their Unix filesystem in such a way
that the inodes become freely extensible, they can easily provide the
kind of human-readable text that I've been talking about.
I simply thought that it would be easier to put an extensible header
in the file itself. If a vendor determines that this is not the case,
then by all means, do it the inode way!
The user just has to know what files
are binary and what files are text (line oriented) files.
This is exactly the situation we should be trying to avoid. We want
the computers to do nearly everything automatically. Of course, the
human user will have to learn a few basics, such as the fact that it
is not such a good idea to stuff a floppy in the CD-ROM drive.
Just try
the split command on an arbitrary file. If you are lucky it will find
NLs sufficiently often to not abend due to overflowing a static
buffer.
Well, I would agree that it is tragic that some programmers did not
know or did not care about overflowing buffers. This is also one of my
pet peeves. However, I do not see what this has to do with data
announcement.
Just because this is a hard migration step for Unix does not mean that
we should not spec it out and start pushing for its inclusion in the
next POSIX release.
I agree completely. We should spec a new system call, called new_open
or whatever. Whether this system call derives the ASCII header from
the "file" itself, or from the inode, is immaterial. (It's an
implementation detail.)
These days it even has a bar code strip that I can't read but
I am sure the machine at the post office can.
What if you take this bar code to some other country's post offices?
Will they also be able to make sense of it? In some cases not, right?
Now do you see the value of human-readable information?
Yeah, I know a fancy mail
reader can suppress the junk headers, but simple programs should be
simple.
I couldn't agree more strongly! Simple is best. Even the most dense
programmers out there will then get it right.
Cheers,
EvdP