WHY doesn't C know anything about directories?

[Mark McIntyre]

Ditto for VMS.

although sys$system: is hardly a simple letter.

--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

 

[David Thompson]

Richard Heathfield wrote:

It's been a long time since I used CMS, but considering the amazing
and sometimes frightening extent of IBM's emphasis on compatibility I
rather doubt it's changed, and it did have a (native) single-level
directory per minidisk. (Really per virtual disk, but in practice the
virtual disks are minidisks.) Plus AIUI access to OS-formatted volumes
and their catalogs if authorized, which I wasn't.

What people often focus on in Unix, and laterDOS/Win, and even
laterMacOS, is _hierarchical_ or _nested_ or _tree-structured_
directories. This is indeed a very useful feature and was an important
advance Way Back When, but it is an additional level up that is not
inherent in a directory to be used and useful as such.

To that list, I can add *HP NonStopKernel*, I guess the installation at
AOL uses the Unix like interface, but many still run under Guardian,
which means no directories.

Again not really. Guardian has collected and organized-by-name
metadata per volume, which is enough to be called a directory in my
definition. It's easy to enumerate 'subvolume's within volume and
file(name)s within subvolume; easy enough to enumerate temp files (if
you want them) which are (annoyingly) not in any subvolume; and
possible though annoyingly different to enumerate volumes. It is even
possible to enumerate multiple nodes, over which files (and other
things like processes) can theoretically be transparently distributed,
although in practice that transparency tends to get dingy pretty fast.
You do need to figure out what you want to do, if anything, about
partitioned files, which actually appear on multiple volumes and even
multiple nodes when people have been drinking the Kool-aid.

The bigger problem IME for many C-ites on Guardian is the extremely
limited file_name_ syntax: only 8 chars subvol and 8 chars file, only
caseinsensitive alpha and digits, NO controllable punctuation at all.
<ObTopic> The standard header names are actually mapped e.g.
stdio.h is really a file named STDIOH, etc. </> And another problem
area is process management and IPC, which are quite different from the
other common models (Unix and M$Win). Sockets are also a little bit
different, but not moreso than Unix-to-M$Win.)

From my own experience, I am more in agreement with Chris T's
argument: the common denominator ends up too low to be worth it.
Common LISP put a lot of effort into doing portable file-name
structures, back when variation in filesystems was more widely and
commonly experienced than now, but punted* on directories.

(* in the American-football sense, not the small-riverboat sense)

- formerly david.thompson1 || achar(64) || worldnet.att.net

 

[David Thompson]

On Tue, 05 Jun 2007 12:25:06 -0700, Lew Pitcher

IMHO, the existing definition of the C language already has enough in
it to permit "directory" operations without needing additional
features. <snip>
Want to enumerate the files within a directory? This hypothetical
implementation could offer a stream consisting of newline delimited
filenames when a specific filename is read. <snip>

Not if a filename can include a newline character -- as is legal on
Unix, though in every case I've seen it used a supremely bad idea.
(Backspace, or (bare) carriage-return, is usually even worse.)

And if a filename can include a null character -- which Unix cannot,
but ISTR something else maybe MacClassic can -- then the 'obvious' way
of using fgets() won't work right. (Although of course improvements on
fgets() are ontopic here and indeed quite frequently discussed.)

It would work to make it newline-delimited _prettified_ (e.g. escaped)
filenames, if fopen() et al handle the same, AND either users already
understand them, or users are trained to understand them, or we also
have (and standardize?) some user-interface aids for them.

But by this point it's no longer so trivial.

- formerly david.thompson1 || achar(64) || worldnet.att.net

 

[Richard Tobin]

And if a filename can include a null character -- which Unix cannot,
but ISTR something else maybe MacClassic can -- then the 'obvious' way
of using fgets() won't work right.

If a filename can contain a nul, fopen() isn't going to work on it.
If the implementation hasn't solved the problem for fopen() (e.g. by
some escaping mechanism), it probably doesn't make things much worse
if it omits the file from the directory listing.

-- Richard

 

[Dik T. Winter]

> On Tue, 05 Jun 2007 12:25:06 -0700, Lew Pitcher

>
> Not if a filename can include a newline character -- as is legal on
> Unix, though in every case I've seen it used a supremely bad idea.
> (Backspace, or (bare) carriage-return, is usually even worse.)

Oh, well, that has been solved, back when somebody within a Unixy
environment thought of null-delimited lists of filenames. Now what
*is* a bad idea is a carriage-return in your password for Unix, but
that's another story.

> And if a filename can include a null character -- which Unix cannot,
> but ISTR something else maybe MacClassic can -- then the 'obvious' way
> of using fgets() won't work right. (Although of course improvements on
> fgets() are ontopic here and indeed quite frequently discussed.)

MacOS also not, as far as I know, in any of its incarnations. But if
an OS allows null characters into its filenames, it better also includes
some translation mechanism from C strings to filenames, vv. That is not
so very difficult.