Re: multiple dots in filenames

[Bruno Haible]

Hello Aharon,

> The conventions are those of GNU Gettext, which I treat largely as a
> black box.  We need to convince Bruno Haible, the gettext maintainer,
> that making this change is worthwhile, and then I have no problem
> following suit.

No, I'm not convinced: VMS has been a time sink for the last 10 years,
causing huge porting efforts for a tiny developer community. Take two
examples:
  - I spent days trying to work around some limitations in VAX cc when
    trying to port GNU clisp. Then I abandoned the port, and noone asked
    for this port in 8 years.
  - I regularly updated Makefile.vms in GNU libiconv and GNU gettext.
    A year ago, I removed the support, and noone even noticed.

> Bruno: the problem is that on VMS, with the exception of the very newest
> kind of filesystem, which usually is not the default, files with multiple
> dots are not allowed in filenames.  VMS tar extractors automatically
> rename such offending files (with different extractors picking different
> conventions, of cousre), but CVS doesn't.

1) How come this is not documented? You can read in the OpenVMS 8.3
   documentation
      
http://h71000.www7.hp.com/doc/83final/5763/5763pro_021.html#posix_names_on_vms
   that the only forbidden filenames on VMS are those
      containing .DIR, or
      ending in a period, or
      containing a file component ".", or
      containing a slash or NUL inside a file component.

2) There is a difference between run-time requirements and build-time
   requirements. The use of a file named Makefile.in.in is a build-time
   restriction; you can assume a developer does some effort to set up a
   suitable environment. I cannot use e.g. gnulib-tool on SMB filesystems
   on Linux; I cannot build programs on NFS filesystems if there is a time
   skew between the server and the client; so I don't do that: I use other
   filesystems instead.

3) You are saying the problem is in the VMS port of the 'cvs' program. Why
   not fix that instead?

4) It's not reasonable to expect GNU program maintainers to spend time on
   this: the GNU standards tell us that even portability to Unix systems
   can be declined when it causes too much trouble:
     "Supporting a variety of Unix-like systems is desirable, although
      not paramount.  It is usually not too hard, so you may as well do it.
      But you don't have to consider it an obligation, if it does turn out to
      be hard."

> VMS is far from dead; it's still supported (and I think actively developed)
> on the Itanium architecture, there are lots of Alphas around, and also
> Vaxen (either real, or inside emulators).

Yes, but with approximately 0.2 people helping the GNU project on it,
reporting bugs, etc. it does not appear as a reasonable porting target.

> As far as I can see, it's mainly Makefile.in.in that would need
> renaming. (I don't know about the two files with @ in their names;
> maybe those as well, Pat?)
> 
> IMHO if the change is so simple, I would suggest moving to Makefilein.in
> so that VMS has a chance of adopting gettext.

The porters can do so in the VMS ports. I don't care. But please don't waste
my time with such requests, if the porters are not willing to spend the time
installing the appropriate file systems on their machines.

> In any case, I wanted to let you know about this if it hasn't come
> up before.

It hasn't come up before. The previous VMS ports of GNU gettext assumed the
'tar' utility renamed the files in a particular way.

Bruno