When I doo my work on system after system, I find that it would be helpful to
hav a function that by the local rules split a filename-string into components.
Becauz this is so local, I would hav the standard require onlie the abuv
described declaration, and one operation, which applys on all (but one) of the
systems that I know enough of.

The required operation, with "p" and "v" 0, marks the beginning of the
filename part, after node, devise, directorie, ...:
        On DOS, Unix, VMS, this
                fnpars("f.c", 0, 0)
        yields a pointer to "f", but on the Guardian to "c".
Whatevver happens, the yielded pointer points to a character of the string,
or the NUL, or (on error) is NULL.

The structuredest file-spec that I know of belongs to VMS:
        node::disk:<di.rec.to.rie>file.x;v
On VMS the required operation points to "f".  DOS has at least
        disk:\di\rec\to\rie\file.ext
and the required points to "f".  Unix is simpler:
        di/rec/to/rie/file.x
--points to "f".  On the Guardian:
        \system.$disk.subvol.file
I skip CMS, becauz its scheme differs from anie other:
        filename filetype filemode
and "filemode" is a letter and a digit, wherof the letter works the same as
the aforesaid "disk"s.  My experiens with CMS and the rest suggests that we
consider CMS wrong.

The most useful operation, after the one required, probablie is marking the
"extension".  This is defind for all the abuv described naming schemes but the
Guardian, and poorlie for Unix.  For the Guardian, if at all implemented, the
pointer can point onlie to the NUL after the string.  As for Unix, "f.o" is
indeed well establishd, but not required by the filesystem.  Therefore, a
Unix-implementation needs to decide whether the first or the last dot marks
the extension.  SCCS-file names would suggest that the last.  The C-shell
agrees with that.

Then maibe it is useful to split the local part from the system-name.  On VMS
that is after "::" if that is in the string, and otherwize the hoal string.
On Unix this varies, and is there onlie in the right context.  For UUCP, it
is after the last "!", for "rcp"-form it is after the first colon, for DECNET
it is after "::" (borrowd from VMS).  Here "v" is useful, for there is no
knowing where the local part beginns unless a format is assumed, and one Unix
system can be linkd in all three wais.

There is further use for "v" in splitting a long directorie-portion into parts,
or deciding which ere the last dot marks the "extension" in Unix, if not the
last.

Error is markd by returning nullpointer: the operation is not known, "fn" is
NULL, it points to an ill formatted string ... but in no case is existens of
anithing relevant to the parsing, which shall confine itself to the apparent
form.

I would like it best, though, if for evveriething found in a VMS file-spec
there were an operation, and if not known to that system the pointer is left
in between, as it were.  That is, asking for the local part and the directorie
yields the same pointer when tryd on Unix, asking for verzion-number yields
pointer to NUL when tryd not on VMS (or TOPS-20), and so on.
                           -*-**-*-**-**-*-
Justice is incidental to law and order.  -- J. Edgar Hoover