> Are you saying:
>
> concat_dirnames("C:\foo", "bar") == error?
Yes. Even if the file spec tool was smart enough just like you and me
it would never be able to unriddle what output it would have to produce
as a result of the following call on Mac:
concat_dirnames("disk:dir_a", "dir_b");
if "disk" was a disk, then the result should be
disk:dir_a:dir_b
if "disk" was a directory
:disk:dir_a:dir_b
Now let's have a look at this call on windows:
concat_dirnames("c", "dir_a\dir_b");
Try to guess what I mean by "c" there? A directory or the disk C?
I hope it's clear for you now why concat_dirnames() can't glue anything
together but dirnames. File Spec is a lack of information on what "disk"
and "C" are. That sort of information has to be provided by user. And
the user really does that when he/she/it chooses an appropriate function --
concat_dirnames, concat_pathnames, prepend_volume and so forth.
> Which isn't clear from the example I gave above since ":mydisk:a" is
> ambiguous on MacOS.
>
> To be clearer: concat_dirnames("b", "/foo") == error.
As long as concat_dirnames() will be taught to divine whether its arguments
are absolute paths or relative paths, it could easily rotate its arguments
so the above-mentioned call would become concat_dirnames("/foo", "b"). At
long last the name "concat_" doesn't furnish a security in which order it
will glue its arguments. For instance, if we had the append_dirname()
function,
then yes:
append_dirname("b", "/foo")
that call is surely fallacious.
