Date: Tue, 2 May 2000 14:13:53 +0300 (IDT) From: Eli Zaretskii X-Sender: eliz AT is To: "Peter J. Farley III" cc: djgpp AT delorie DOT com Subject: Re: Question about running configure script In-Reply-To: <390e0378.27082543@news3.banet.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 Precedence: bulk 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.