Jan Nieuwenhuizen wrote:
> > the processor that interprets
> > #include "c:/foo.h"
> > #include "C:/FOO.H"
> > #include "C:\\FOO.H"
> > cannot just assume that different file names correspond to different
> > files on disk.
>
> Yes, but this example shows the mixing of three problems:
> (1) wrong drive letter casing,
> (2) difference in type of slash,
> (3) difference in casing of the file name.
I claim that
* Caring about (1), (2), (3) should be done in utility functions outside of
realpath(), since they can be useful even on relative file names.
* When you are in situations where (3) is a problem, caring about (1) or (2)
but not (3) is not helpful.
* Caring about (2) is helpful when passing file names to other programs via
the command line, namely:
- when you pass a file name to a Java-based program on Windows, you need
to convert '\\' to '/', in order to avoid interpretation of '\\t' and
such,
- when you pass a file name to other Windows programs, you need
to convert '/' to '\\', in order to avoid interpretation of '/something'
as a command-line option.
In some programs with less techy users, converting '/' to '\\' may also be
useful to avoid confusing the user.
* Caring about (1) without (2) is just cosmetics.
Bruno
