Date: Wed, 10 Dec 1997 11:33:04 +0200 (IST) From: Eli Zaretskii To: Esa DOT Peuha AT Helsinki DOT FI cc: djgpp-workers AT delorie DOT com Subject: Re: Patches for djtar In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Wed, 10 Dec 1997, Esa A E Peuha wrote: > > Note that the seemingly large change in the `get_new_name' function is > > just a reindentation, since the code indentation was left intact after > > it was copied from an inner block, which made the program structure > > hard to read. > > So the -b switch to diff was a bad idea... You should *NEVER* use -b when submitting patches, because they confuse `patch'. I had some very uneasy correspondence with DJ when he couldn't apply my patches, until I figured out that -b was the culprit. > This is not trivial. The main function must read four bytes from the > beginning of the file, but those four bytes must also be available to the > untar/unzip code. The input file might not be seekable (if it is raw > disk), and it might not be possible to open the file, read the bytes and > close it to be opened again (if it is stdin). But if anyone can think of a > solution, then please implement this. How about an old and ugly hack of keeping the first two bytes in a global variable? > I think that's a false analogy. Previously, every file had to be untarred > after decompressing, so there was no point to ask what to do with the > file, but now a zipped .tar file can be reasonably considered either as a > .zip file or a compressed .tar file, so the user might want to choose the > format. I was talking about the automatic detection of the compression method. As far as I could see that's the only thing that .zip extension is checked for. Did I miss something?