From: Beman Dawes (bdawes_at_[hidden])
Date: 2002-03-04 12:03:38
At 03:08 AM 2/26/2002, Jan Langer wrote:
>> >>How absolute() does its job internally is an implementation detail;
>> >>isn't a good argument for exposing getcwd/chdir.
>> >what should absolute() do? it isn't mentioned in the requirements as a
>>Because I'm not sure if it is in fact a requirement. It would take a
>>and return an absolute path (which might in fact be the same string).
>this function would imply current_directory (). if you call absolute
>("") you should get the current directory but you cannot set it. i would
>prefer supporting either both or none.
>ps: i changed the code so that the directory_iterator changes an
>empty string to "." in its ctor.
At 08:43 AM 2/26/2002, Jan Langer wrote:
>>several questions which came up during writing:
> - how can i delete the current directory? remove ("");
> or in other words: should the posix-impl replace all occurences of
>"" by "."?
I've been thinking a lot about Jan's two messages above, and I'm convinced
he has identified a serious weakness. We don't want any trap doors that
allow access to the current working directory.
(Rationale: "current working directory" is in effect a global variable. For
why that is a serious problem, put "global variables considered harmful"
OTOH, we do want programs like "ls" or "dir" to be able to supply a default
starting point in the directory tree.
The solution is to remember that while global variables are disastrous,
global constants are relatively harmless, at least if initialization can be
The initial_directory() function below is the closest I've been able to
come to that ideal. Comments appreciated.
I've also included root_directory() and some TODO items, for comment.
The upshot of all this is that the answer to Jan's question about the
meaning of "" as a path is either:
(1) An error.
(3) seems totally wrong a lot of the time. (2) is sometimes the intent,
but it might also be simply an error. (1) is safest; it means you have to
explicitly write initial_directory() if that is what you mean. Programs
would read more explicitly. My guess is that (1) would detect a fair
number of errors at very little user cost. But we need to figure out if ""
has some well defined meaning (as a pathname, not as a command line
argument) on certain platforms.
template< typename CharT >
Effects: The first time called, stores an absolute directory path.
The path is determined as if by the following:
If possible, the path of the initial working directory
when main() was called. Otherwise, if possible, the current
working directory. Otherwise, root_directory().
Returns: The stored path.
Rationale for not simply specifying the return as "initial working
directory when main() was called": That directory isn't known on all
platforms; indeed there may not even be a concept of "current working
directory". The semantics are chosen to come as close to that as possible.
Note: It would be a good practice in a program dependent on
initial_directory() to call it immediately on entering main().
That protects against a called function altering the current working
directory (using a native platform function) and then calling
template< typename CharT >
Returns: The absolute path for the file system's root directory.
Note: The value of the root directory string is specified in terms
of its effect if passed to a basic_directory_iterator constructor.
The resulting iterator would iterate over all the entries in the real (in
the case of POSIX) or virtual (in the case of Windows) directory. On some
platforms (Windows), the root directory will be read only, and all the
entries in the root directory will have funny names (a:/, b:/, c:/, etc.)
TODO: That definition needs to be expanded so root_directory() works
correctly and portably in path composition and other uses.
TODO: We need a safe way to turn a relative path into an absolute path.
Perhaps absolute( relative-to, path ) which returns path if it is already
absolute, or path( relative-to, path ) if path is relative.
TODO: We need an overall review of what "" means as a path arg in all file
system functions (not just the ones in this header.)
TODO: Two argument path composition is hopeless in trying to write real
code. Need n-argument. (I realize that argues for a path composition type
which could overload operator+ appropriately. I'm not thinking of replacing
the string type in all path args, just the possibility of a path
composition type used only when composition is needed, with an automatic
conversion to string.
--- end ---
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk