Re: [jamboost] bbv2 path module questions

From: Vladimir Prus (ghost_at_[hidden])
Date: 2004-10-22 05:29:20

Hi Johan

> I've started out working on VMS support for the path module and have a
> couple of questions:
>
> - In a previous posting you mentioned some neccessary fixes with regards to
> non-portable paths being used in the kernel module - did you change that?

No. If fact, I suspect fixes would be necessary but don't yet know where.

> - Should conversions of portable paths including the ".." into native paths
> be supported (I can't see any current tests for that - maybe because the
> current platforms have the same notion as the portable path for parent
> directory)? The VMS equivalent is "-".

I think yet. At least ".." in portable paths are allowed.

> - What about "." - is it used in portable paths at all? The VMS equivalent
> is "[]".

Yes, it's used. The most common usage is:

exe foo : foo.cpp : <include>. ;

> - The big question (which requires a little bit of preamble, actually):
>
> The VMS path specification goes along the lines of disk:[dir]file, so
> converting that into the portable path renders "/disk:/dir/file". Now to
> the $10.000 question: How on earth could I reliably convert that back into
> a native path? No can do. There's no way of knowing if the last part is
> directory or file in this particular case.

Oops!

> I've thus limited myself to assume that the file part of a portable path
> has to match "^[^\.]+\..*$". 

Essentially, that it has a dot?

> If not - I assume it's part of the path spec. 
> I was also considering how to perhaps lessen the problem: would it be a
> good idea to always append a "." to filenames missing an extension when
> converting the into portable formats, e.g.:
>
> "disk:[dir]file" => "/disk:/dir/file." (note trailing dot)

I think that on VMS, adding the dot when creating portable path is a good 
idea.

> A problem here is that the relatively new ODS-5 file system also supports
> dots in path specs. To create such directories one have to use the
> circumflex escape character, e.g.:
>
> create/dir [.sub^.dir] => create subdirectory "sub.dir".
>
> As I find this extremely confusing (imagine embedded "/" in unix directory
> names) I simply won't bother to handle this (for the time being, at least).

Seems reasonable to me.

- Volodya