bug-gnu-utils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: m4 files not unique in 8.3 environments


From: Eli Zaretskii
Subject: Re: m4 files not unique in 8.3 environments
Date: Sat, 26 Feb 2005 20:46:54 +0200

> From: Bruno Haible <address@hidden>
> Date: Sat, 26 Feb 2005 19:02:01 +0100
> Cc: address@hidden, address@hidden
> 
> > Even under VFAT, these file names might still clash, because when the
> > tarball is unpacked, Windows creates the 8+3 aliases for the long file
> > names.  Under some Windows configurations, these aliases will clash
> > and cause trouble.
> 
> Is this the default Windows configuration? Or about which configuration are
> you talking?

It happens if one disables name-numeric-tails.  Which is necessary if
one wants the same installation to work on both DOS and Windows.

> > In addition, there's the DOSEmu emulator (part of GNU/Linux systems)
> > which doesn't yet support long file names, and so is limited to 8+3
> > file names.
> 
> dosemu is being used like STONX: for playing old games. Not for doing
> development any more.

I don't know on what data are you basing these assertions.

> > Even if the DJGPP port of gettext itself is not actively maintained,
> > the gettext files do wind up in other packages that use GNU Gettext.
> > (That's how Paul became acquainted with this issue.)
> 
> These packages can use a fnchange.lst file

They could, but fixing 2 file names is better, and I really don't see
why should it be such a big problem.  They aren't magic file names,
are they?

> > If you need a DJGPP-knowledgeable person to help you find solutions
> > for related problems, you will find them on address@hidden
> 
> This mailing list has become quite silent: only 155 mails since 2005-01-01;
> it looks much like end of life of this project.

Try telling that to DJ Delorie.

> > Could you please find a solution to these two file names?
> 
> You have more knowledge than me how to apply the fnchange.lst trick.

So it's NO after all.  Too bad.

Thanks for your time, anyway.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]