Date:	Tue, 2 May 2000 14:13:53 +0300 (IDT)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	"Peter J. Farley III" <pjfarley AT banet DOT net>
cc:	djgpp AT delorie DOT com
Subject:	Re: Question about running configure script
In-Reply-To:	<390e0378.27082543@news3.banet.net>
Message-ID:	<Pine.SUN.3.91.1000502141322.22132H-100000@is>
MIME-Version:	1.0
Reply-To:	djgpp AT delorie DOT com
Errors-To:	nobody AT delorie DOT com
X-Mailing-List:	djgpp AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

On Mon, 1 May 2000, Peter J. Farley III wrote:

> >> C:\>djtar -x -v -!. co991215.tgz
> >
> >The -!. part is IMHO not a good idea.  It disables the automatic
> >conversion of some invalid file names that are frequently met in
> >tar.gz archives of the Unix origin.  djtar then prompts you for a
> >valid name for each of these files, which can be quite a pest if the
> >number of such files is large.
> >
> >Why did you suggest to use that option?
> 
> Since the package the original poster asked about was *not* a GNU
> release, the types of invalid file names you refer to are (in my
> experience -- YMMV) less likely to occur.  Using this option preserves
> *all* periods in file names, all of which are perfectly legal under
> Win9x DOS boxes -- which is where I strongly suggested the OP should
> be operating.

First, the original poster clearly used DOS, not Windows (he said the
configure script was called `configur').

And second, the -!. option has no effect whatsoever on an LFN
platform.  The code which renames file names is disabled under LFN, so
you always get the original names from the archive, whether or not you
use the -!. option.

> What unix file names would pose a problem in an LFN environment?

I was talking about DOS, not Windows.

> >I have yet to see a package that really requires LFN to be built.  A
> >few simple (and fairly standard) tweaks of the configuration scripts,
> >that's all that's needed to overcome the file-name problems.
> 
> True, as far as GNU-released scripts and applications are concerned.
> I have seen non-GNU-produced application-specific packages that use
> GNU-like facilities but do not make any portability changes in the
> *application* scripts and code.  This frequently then requires a
> non-LFN porter of such an application to have to really dig into the
> application code to find all of the nonportable code and change it.

That's true, but it does not necessarily have anything to do with LFN.
File names that are invalid on DOS are usually not the most important
issue when non-portable code is considered, and once spotted, these
problems are easy to fix.

> Note, I do *not* say that such packages can *not* be made LFN-clean.
> I simply point out that for application packages it is often more work
> than someone who is only interested in the application itself is
> willing or knowledgable enough to perform.

Granted, a port is not a trivial job.  What I was pointing out is that
the LFN-related issues are minor compared to the rest of the porting.

Also note that I was talking about _building_ a package, not _using_
it.  The LFN-related issues in the application code (as opposed to
such problems in configuration and build scripts) will not be apparent
until you run the program.

- Raw text -