DJ Lucas wrote:
Well, zlib is already out of the equasion. I suppose the next logical question is: What does the shared libunzip bring to the table?
Tushar said "speed because of shared code in unzip", but he is wrong.
More importantly, in my own ignorance, how exactly can one use the shared library without a header file to describe it?
The relevant header files are "unzip.h" and "unzvers.h". Install them and use the library. But the BLFS policy is that libraries used by none of BLFS packages should not be installed.
I can't believe I hadn't noticed that before. I agree with Alexander's suggestion. Any additional concerns?
Switching to "linux" target eliminates the need for dont_make_noise patch.
The other question still stands. Should I bug zlib developers about these files that it can't handle? It does hinder operation of other projects that use zlib (python's zip modules).
Can't comment here.
Also, Alexander, while I've got your attention. I'm not sure 'fully-functional' is a correct term WRT the UTF8 issues.
Of course, you are right here in your doubt. The filename issue does exist and it makes WinZip+Wine more functional than unzip.
I'm attempting to travel that path now with en_US.UTF-8. Only way to learn is to dive right in! :-) On my previous build (not utf8), I had found several files created with a .Net application that I couldn't do operations on using the list of files in vim.
Sorry, I can't judge based on your description. "echo * | xxd" is the information I need.
Certain apostrophy characters (') displayed as blocks. If I understand the issue correctly, the filenames are the only problem for me in en_US as unzip will correctly change the extracted filenames.
The filename issue doesn't exist in en_US with archives created in DOS by anything, in Windows by either WinZip, WinRAR or the builtin XP ZIP folder support, or with archives created on another UNIX in en_US locale. You can't easily extract ZIP archives from Mac OS X or from RedHat distros, because they use UTF-8 as the filename charset and pretend to be UNIX (thus, unzip does no filename conversion while it should convert fron UTF-8 to ISO-8859-1).
In en_US.UTF-8, the filename issue will exist for DOS/Windows archives and for UNIX archives created in en_US locale. Fedora and Mac archives will just work.
In your case, it looks like the .NET software forgot to recode filenames (i.e. call the CharToOem() function), but set the "Creator OS" to "DOS/Windows" and is thus broken. However, I am not able to construct a detailed explanation exactly matching what you see.
As for file contents, the situation is as follows. In all cases, the extracted file will contain the same bytes as the original one. That doesn't mean that if you extract a text file, you will be able to "cat" it and read what your monitor displays (this is indeed the issue with Windows text files because they are in ISO-8859-1). Vim by default detects attempts to view non-UTF-8 text files in UTF-8 locales, and converts them from ISO-8859-1 to UTF-8. 'vim -c ":help fileencodings"' for more details.
-- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
