Comments on: Relative filenames - relative to what?
In R2 relative file names are relative to system/script/path.
In R3 A77, they will be relative to the current directory (from calling the OS).
So, which is best for R3?
Update (5-Aug):
Ok, to clarify:
When any file or directory action is used (READ, WRITE, OPEN, etc.), if a relative path is given, it is converted to an absolute path in order to check security (within whatever sandbox policies you've set up.)
This conversion requires an absolute path, which is obtained from the "current directory". This is a "process state variable." It can be stored in one of two places: in a REBOL object or in the OS. As long as the CHANGE-DIR function is being used, those two should, in theory, be identical. (Which is why you don't notice that R2 actually manages it's own copy.)
However, as Kaj points out, nearly all other languages use the OS value. This issue is important for a few reasons:
- consistency with launched subprocesses that use the OS current dir.
- some debug tools and monitors show the current dir.
- some OSes let you change-dir a running process (for whatever reason).
There may be additional issues, which is why I'm posting this for comments.
8 Comments Comments:
Brian Hawley
4-Aug-2009 23:02:37 |
When will they be relative to the current directory? At the top level? During the script's execution?
When last I checked, scripts changed directory during the script's execution so they could load other scripts from paths relative to the directory they are in. Such scripts could be changed to explicitly reference system/script/path, except for in the Needs header (unless LOAD is also changed to be relative to system/script/path).
The calling OS's path at startup is still system/options/path, except for platforms like WinCE that don't have the current directory concept.
I'm not sure what you're proposing here. Would you please elaborate? | Kaj
5-Aug-2009 9:13:43 |
Paths relative to the current working directory are more consistent with other languages.
There still needs to be an easy way to reference the location of the script. In Syllable, paths starting with ^/ resolve to the path of the executable, similar to ~ for the user's home directory. Maybe this is an idea for R3? | Carl Sassenrath
5-Aug-2009 15:09:54 |
Brian, I posted an update to clarify.
Kaj, system/options and system/script hold references to locations... of course, I noticed the word "easy" in your wording.
Part of the problem is that often (these days) data storage is not in the script's directory, but in some user-specific data directory somewhere. So, the script's dir may hold includes or constants, but not active data.
Also, note that for file types, refinements are path appends. So:
read system/options/path/myfile.txt
is a clean, readable, and valid file path specification (no % prefix).
As for a special char, something like ... might be ok, since most OSes already use . and .. but not ... to indicate directory actions (that I know of, but perhaps there are ones out there.)
The ~ will be user home. Although not defined on Win32 (that I know of) it could be allowed in REBOL code. (Make a suggestion as to what's preferred here.)
| Brian Hawley
5-Aug-2009 17:08:46 |
The user home is defined in Windows, but given a different environment variable: USERPROFILE. However, Windows tends to have a little more organization to their user settings than Unix, so some applications tend to use the APPDATA directory as their user home equivalent.
It all depends on whether ~ is supposed to be a place to store per-user application data and settings, or whether you want access to the entire user's profile, including their personal documents. | Kaj
6-Aug-2009 6:38:28 |
I think ... is used in some advanced file systems to access extended attributes of a file or directory. | Greg Schofield
7-Aug-2009 22:28:52 |
Have a look at www.lestec.com.au/aui/aui.cgi, it generates Anonymous Unique Identifiers, I helped design it with Lestec, to overcome a number of problems in a number of different areas, most importantly file references.
The idea is that running a single serial process on request from a static IP address, a world wide unique identifier is generated. Example "qj4ikdsfruwawl". It consists of a fist letter alpha (ie 26 can be produced from each unique instance) the IP address and a time stamp, rendered into a base36 code (it has been designed to be unambiguous -- no zero for instance).
Upper case or lower case doesn't matter, the time is reversed giving a good scatter between each ID generated.
It is just a CGI script (the format is important and it took some time to make a serviceable design). On application we are working is to do with file locations, which are kept in a strict hierarchy (26 directories which can be divided by 32 etc.,. 26x36x36)
As a file name it is a relative absolute - point to the general location, and the absolute position can be deducted from the first three letters of the name.
File-names are of course unreadable (not much different from normal ones in my opinion), but they are not intended to be read by humans.
Rebol headers become more important, in fact central, to manipulating files. It does mean that scriptors have to extract a variable assignment rather than a path name. A plain language "title" and a filename, and list locations have to be published (absolute paths to relative positions).
The point in this, is that establishing relative pathnames becomes irrelevant, along with a number of other problems (like data security which is handled at the OS level -- ie a location that is protected for a particular purpose or user -- as far as the system is concerned it is one of handful of places it may need to look for a particular file).
We are also thinking of putting everything in OPF (Open Packaging Format) a zipped directory with a couple of small required files. That provides a file that can tell a great deal about itself without relying on a three letter dot suffix.
There are many positive sides, and of course some negative ones, instead of trying to save a tiny speed deficit, a number of limited locations are searched for any particular file -- if it exists, because it is a unique address, it is opened, if not the next location is used. I don't consider that a significant deficit.
Of course merely browsing directories is impossible, it is a random distribution system and filenames are gibberish. Indexes created by interrogating actual files produce a virtual browse level (how things are grouped is another dimension -- on the positive side).
Everything has to read from zipped files (but zipping could need not be adopted or OPF) for the scripting environment, as Rebol files carry their own headers and that simplifies things a lot.
I am only putting this up to be thought about, there is a whole world of implications involved. But as far as I am concerned the file systems we are use to are well expired of their use by dates. Simple resolutions are possible. | paullys
8-Aug-2009 5:15:57 |
Conservatism is better: til that new behaviour is not decisive, keep R2 manner. | Maxim Olivier-Adlhoch
10-Aug-2009 0:03:18 |
I think the use of the OS current dir would make a difference when using call no?
not checked... but I assume that if I change dir in my application... sub processes should have their current dir set relative to that. While the OS current dir should make this implicit, the can't say its the same for REBOL.
if it doesn't make any difference for REBOL, I'd prefer it be stored in the OS, makes REBOL more friendly with its host, if for no other reason. |
Post a Comment:
You can post a comment here. Keep it on-topic.
|
