On Apr 9, 7:16 pm, m_l_g3 <m_l...@[EMAIL PROTECTED]
> wrote:
> I would like to have WRK-ANCHORED too, to make `pwd`-anchoring
> explicit. Some systems may already have some built-in intellect, and
> this sort of things is always difficult to hack-around.
Thinking this one through ... the thing is, however a system describes
an absolute or relative file hierarchy, just building on top of
INCLUDED and REQUIRED and the FILES wordset means that you inherit it.
And the only thing you can really do extremely portably ... across
basically all operating systems and across all implementations ...
with a current working directory is to presume that the appropriate
tools are in place to point it where the user wants and then do your
work in that current working directory as a flat namespace.
So to the extent that the implementation has extra intelligence built
in, normally if I want a little tool to fit into that implementation,
I think that tacitly inheriting what the local implementation is doing
is workable.
Now, sure, I am playing around in terrain that has a more diversity of
file systems than most people, where portable-across-Windows-and-
Unixen means as-portable-as-necessary.
But where the above falls apart is in two areas:
* a cross-platform set of files that relies on a hierarchy ... even a
very flat, two level hierarchy ... cannot portably run other scripts
below it in the hierarchy.
* a cross-platform set of files to be installed in a library cannot
portably run other scripts from the same library collection.
The two flaws of the F" approach ... one a specific instance of the
other ... is that, first, its better to standardize a non-parsing word
and leave the parsing word as an optional extension, just to reserve
its place so that source that wants to use it is free to:
[UNDEFINED] F" [IF] ( ... define F" ) [THEN]
.... and second, there exist filing systems where " is a valid part of
a file name. Including one of the filing systems I am working with.
Oops.
So, boiling down the two roadblocks to the solution that gets around
the roadblock with the minimum impact on the rest of the system:
ANCHORED ( ca1 u1 -- ca2 u2 )
Translate the relative file reference in the string referred by
( ca1 u2 )
into an absolute file reference.
If executed from within a file script, the reference is relative to
the location of that file script within the file system. If executed
from the command line, the reference is relative to an implementation-
defined location in the file system.
The relative file reference consists of a file name and optional
subdirectory prefix. Any subdirectory name in the subdirectory prefix
concludes with the the subdirectory separator ``/''. The format of the
absolute file reference is the implementation-defined format for use
with the standard word INCLUDED.
The absolute file reference returned by ANCHORED may be over-written
by the next invocation of ANCHORED or LIB-ANCHORED.
LIB-ANCHORED ( ca1 u1 -- ca2 u2 )
Translate the relative file reference in the string referred by
( ca1 u2 )
into an absolute file reference. The implementation provides a library
search path, consisting of a sequence of one or more locations in the
file system. LIB-ANCHORED searches for the first occurrence in the
library search path of a file matching the relative file reference. If
found, LIB-ANCHORED returns the absolute file reference to that file.
If not found, LIB-ANCHORED returns the absolute file reference for the
relative file reference within the first directory in the library
search path.
The absolute file reference returned by LIB-ANCHORED may be over-
written by the next invocation of ANCHORED or LIB-ANCHORED.
|
