[ python-Bugs-1324237 ] ISO8859-9 broken
Bugs item #1324237, was opened at 2005-10-11 21:35
Message generated for change (Comment added) made by exa
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1324237&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Unicode
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Eray Ozkural (exa)
Assigned to: M.-A. Lemburg (lemburg)
Summary: ISO8859-9 broken
Initial Comment:
Probably not limited to ISO8859-9.
The problem is that the encodings returned by getlocale()
and getpreferredencoding() are not guaranteed to work
with, say, encode method of string.
I'm on MDK10.2 and i switch to Turkish locale
>>> locale.setlocale(locale.LC_ALL, '')
'tr_TR'
There is nothing in sys.stdout.encoding!
>>> sys.stdout.encoding
>>>
So I take a look at the encoding:
>>> locale.getlocale()
['tr_TR', 'ISO8859-9']
>>> locale.getpreferredencoding()
'ISO-8859-9'
Too bad I cannot use either encoding to encode innocent
unicode strings
>>> a = unicode('André','latin-1')
>>> print a.encode(locale.getpreferredencoding())
Traceback (most recent call last):
File "", line 1, in ?
LookupError: unknown encoding: ISO-8859-9
>>> print a.encode(locale.getlocale()[1])
Traceback (most recent call last):
File "", line 1, in ?
LookupError: unknown encoding: ISO8859-9
So I take a look at python page and I see that all encoding
names are in lowercase. That's no good, because:
>>> locale.getpreferredencoding().lower()
'\xfdso-8859-9'
(see bug 1193061 )
So I have to do this by hand! But of course this is
unacceptable for any locale aware application.
>>> print a.encode('iso-8859-9')
André
Expected:
1. I expect the encoding string returned by
getpreferredencoding and getlocale to be *identical*
2. I expect the encoding string returned to *work* with
encode method and in general *any* function that accepts
locales.
Got:
1. Different, ad hoc strings
2. Not all aliases present, only lowercases present, no
reliable way to find a canonical locale name.
Recommendations:
a. Please consider the Java-like solution to make Locale
into a class or an enum, something reliable, rather than
just a string.
b. Please test the locale functions in locales other than
US (that is not really a locale anyway)
--
>Comment By: Eray Ozkural (exa)
Date: 2005-10-24 14:01
Message:
Logged In: YES
user_id=1454
First, my system isn't broken. All applications run fine in this particular
locale setting. The system was Mandrake 10.2, and now I have
upgraded to Mandriva 2006, which is the same regarding this matter
(However, I will check once again).
I do not understand your suggestion of not setting the locale to tr_TR. I
am not doing that. I am doing:
locale.setlocale(locale.LC_ALL, '')
which must work for _any_ locale not just one or two. As you know,
that is the standard way of starting up a localized application.
My suggestions stand:
1. Make the locale identifier something else than a string. Make it an
object, just like in Java standard library
2. To _all_ text processing functions affected by locale setting, most
notably lower() and upper() methods, append an optional argument of
locale.
The problem here might be greater than you seem to think it is.
I should be able to use the result of locale.getpreferredencoding()
*without* recourse to any text processing (the frustrating bit here is
that, simply using lower is not sufficient in this case, but that is just a
side matter). The simple answer is that it should return an ID or an
Object that is not text.
I suggest you to also review the Java standard library about these
functions.
At any rate, it is unacceptable for locale-specific functions to not work
in some locales, in a locale-aware application that supports any locale.
Regards,
--
Eray Ozkural, eray at uludag.org.tr
Uludag Developer http://uludag.org.tr
--
Comment By: M.-A. Lemburg (lemburg)
Date: 2005-10-21 14:25
Message:
Logged In: YES
user_id=38388
SF has problems again it seems...
Anyway, I tried to set the TR_tr locale on my system and got
a surprising result:
>>> import locale
>>> locale.setlocale(locale.LC_ALL, 'tr_TR')
'tr_TR'
>>> locale.getpreferredencoding().lower()
'ans\xfd_x3.4-1968'
>>> locale.getpreferredencoding()
'ANSI_X3.4-1968'
So I think the problem lies with the fact that
string.lower() is locale dependent and the GLIBC folks chose
a highly incompatible way of dealing with the special
Turkish situ
[ python-Bugs-1324237 ] ISO8859-9 broken
Bugs item #1324237, was opened at 2005-10-11 23:35
Message generated for change (Settings changed) made by lemburg
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1324237&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Unicode
Group: Python 2.4
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Eray Ozkural (exa)
Assigned to: M.-A. Lemburg (lemburg)
Summary: ISO8859-9 broken
Initial Comment:
Probably not limited to ISO8859-9.
The problem is that the encodings returned by getlocale()
and getpreferredencoding() are not guaranteed to work
with, say, encode method of string.
I'm on MDK10.2 and i switch to Turkish locale
>>> locale.setlocale(locale.LC_ALL, '')
'tr_TR'
There is nothing in sys.stdout.encoding!
>>> sys.stdout.encoding
>>>
So I take a look at the encoding:
>>> locale.getlocale()
['tr_TR', 'ISO8859-9']
>>> locale.getpreferredencoding()
'ISO-8859-9'
Too bad I cannot use either encoding to encode innocent
unicode strings
>>> a = unicode('André','latin-1')
>>> print a.encode(locale.getpreferredencoding())
Traceback (most recent call last):
File "", line 1, in ?
LookupError: unknown encoding: ISO-8859-9
>>> print a.encode(locale.getlocale()[1])
Traceback (most recent call last):
File "", line 1, in ?
LookupError: unknown encoding: ISO8859-9
So I take a look at python page and I see that all encoding
names are in lowercase. That's no good, because:
>>> locale.getpreferredencoding().lower()
'\xfdso-8859-9'
(see bug 1193061 )
So I have to do this by hand! But of course this is
unacceptable for any locale aware application.
>>> print a.encode('iso-8859-9')
André
Expected:
1. I expect the encoding string returned by
getpreferredencoding and getlocale to be *identical*
2. I expect the encoding string returned to *work* with
encode method and in general *any* function that accepts
locales.
Got:
1. Different, ad hoc strings
2. Not all aliases present, only lowercases present, no
reliable way to find a canonical locale name.
Recommendations:
a. Please consider the Java-like solution to make Locale
into a class or an enum, something reliable, rather than
just a string.
b. Please test the locale functions in locales other than
US (that is not really a locale anyway)
--
>Comment By: M.-A. Lemburg (lemburg)
Date: 2005-10-24 16:51
Message:
Logged In: YES
user_id=38388
I can only repeat: Python will not work if you set up the
GLIBC to have it convert ASCII characters from lower to
upper or vice-versa to characters outside the ASCII range.
Please reread my reply.
If you write a locale aware application that deals with text
data, you should use Unicode to store the text data - not
8-bit strings. And no, writing a locale aware application
does not mean that you start it up with setlocale(LC_ALL,
'') - this simply doesn't work and is also the reason why
the locale module goes through great lengths in only
temporarily using this C API in order to apply a few
conversions.
If you think that we should have locale dependent string
conversion functions that work in the same way (temporarily
set a certain locale and then reset it to what it was
previously set to), please provide a patch for the locale
module.
Thanks.
--
Comment By: Eray Ozkural (exa)
Date: 2005-10-24 16:01
Message:
Logged In: YES
user_id=1454
First, my system isn't broken. All applications run fine in this particular
locale setting. The system was Mandrake 10.2, and now I have
upgraded to Mandriva 2006, which is the same regarding this matter
(However, I will check once again).
I do not understand your suggestion of not setting the locale to tr_TR. I
am not doing that. I am doing:
locale.setlocale(locale.LC_ALL, '')
which must work for _any_ locale not just one or two. As you know,
that is the standard way of starting up a localized application.
My suggestions stand:
1. Make the locale identifier something else than a string. Make it an
object, just like in Java standard library
2. To _all_ text processing functions affected by locale setting, most
notably lower() and upper() methods, append an optional argument of
locale.
The problem here might be greater than you seem to think it is.
I should be able to use the result of locale.getpreferredencoding()
*without* recourse to any text processing (the frustrating bit here is
that, simply using lower is not sufficient in this case, but that is just a
side matter). The simple answer is that it should r
[ python-Bugs-1324237 ] ISO8859-9 broken
Bugs item #1324237, was opened at 2005-10-11 21:35
Message generated for change (Comment added) made by exa
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1324237&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Unicode
Group: Python 2.4
Status: Closed
Resolution: Wont Fix
Priority: 5
Submitted By: Eray Ozkural (exa)
Assigned to: M.-A. Lemburg (lemburg)
Summary: ISO8859-9 broken
Initial Comment:
Probably not limited to ISO8859-9.
The problem is that the encodings returned by getlocale()
and getpreferredencoding() are not guaranteed to work
with, say, encode method of string.
I'm on MDK10.2 and i switch to Turkish locale
>>> locale.setlocale(locale.LC_ALL, '')
'tr_TR'
There is nothing in sys.stdout.encoding!
>>> sys.stdout.encoding
>>>
So I take a look at the encoding:
>>> locale.getlocale()
['tr_TR', 'ISO8859-9']
>>> locale.getpreferredencoding()
'ISO-8859-9'
Too bad I cannot use either encoding to encode innocent
unicode strings
>>> a = unicode('André','latin-1')
>>> print a.encode(locale.getpreferredencoding())
Traceback (most recent call last):
File "", line 1, in ?
LookupError: unknown encoding: ISO-8859-9
>>> print a.encode(locale.getlocale()[1])
Traceback (most recent call last):
File "", line 1, in ?
LookupError: unknown encoding: ISO8859-9
So I take a look at python page and I see that all encoding
names are in lowercase. That's no good, because:
>>> locale.getpreferredencoding().lower()
'\xfdso-8859-9'
(see bug 1193061 )
So I have to do this by hand! But of course this is
unacceptable for any locale aware application.
>>> print a.encode('iso-8859-9')
André
Expected:
1. I expect the encoding string returned by
getpreferredencoding and getlocale to be *identical*
2. I expect the encoding string returned to *work* with
encode method and in general *any* function that accepts
locales.
Got:
1. Different, ad hoc strings
2. Not all aliases present, only lowercases present, no
reliable way to find a canonical locale name.
Recommendations:
a. Please consider the Java-like solution to make Locale
into a class or an enum, something reliable, rather than
just a string.
b. Please test the locale functions in locales other than
US (that is not really a locale anyway)
--
>Comment By: Eray Ozkural (exa)
Date: 2005-10-24 15:08
Message:
Logged In: YES
user_id=1454
I had read your reply very carefully. Had it
made sense, I would think that this bug was
invalid. However, it is not invalid. More
explanation below. Please read carefully.
First, we are not foolish enough to store the text as
8-bit strings in our application. All text is stored as
UTF-8, if that is what you are wondering.
This bug report is wholly concerned with
the question: Why does not the following
function work?
>>> print a.encode(locale.getpreferredencoding())
where a is obviously unicode. What makes
you think it is not unicode? It was indicated
carefully in the original report.
What use is encode(.) function if this is
not supposed to work on _every_ locale? Why
should my glibc have anything to do with
the failure of this function?
Again, the bug that lower() and upper() are
broken is the subject of an existing report.
This bug report is concerned with the above
issue, the incapacity of the lower and upper
functions is completely irrelevant to this
bug.
Second, you say that ` setlocale(LC_ALL,
'') ` simply doesn't work. I request your
wisdom then, perhaps you can also help
the authors of the gettext manual then,
what is the correct way to initialize an
application which uses gettext?
--
Comment By: M.-A. Lemburg (lemburg)
Date: 2005-10-24 14:51
Message:
Logged In: YES
user_id=38388
I can only repeat: Python will not work if you set up the
GLIBC to have it convert ASCII characters from lower to
upper or vice-versa to characters outside the ASCII range.
Please reread my reply.
If you write a locale aware application that deals with text
data, you should use Unicode to store the text data - not
8-bit strings. And no, writing a locale aware application
does not mean that you start it up with setlocale(LC_ALL,
'') - this simply doesn't work and is also the reason why
the locale module goes through great lengths in only
temporarily using this C API in order to apply a few
conversions.
If you think that we should have locale dependent string
conversion functions that work in the same way (temporarily
set a certain locale and then reset it to what it was
[ python-Bugs-1324237 ] ISO8859-9 broken
Bugs item #1324237, was opened at 2005-10-11 23:35
Message generated for change (Comment added) made by lemburg
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1324237&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Unicode
Group: Python 2.4
Status: Closed
Resolution: Wont Fix
Priority: 5
Submitted By: Eray Ozkural (exa)
Assigned to: M.-A. Lemburg (lemburg)
Summary: ISO8859-9 broken
Initial Comment:
Probably not limited to ISO8859-9.
The problem is that the encodings returned by getlocale()
and getpreferredencoding() are not guaranteed to work
with, say, encode method of string.
I'm on MDK10.2 and i switch to Turkish locale
>>> locale.setlocale(locale.LC_ALL, '')
'tr_TR'
There is nothing in sys.stdout.encoding!
>>> sys.stdout.encoding
>>>
So I take a look at the encoding:
>>> locale.getlocale()
['tr_TR', 'ISO8859-9']
>>> locale.getpreferredencoding()
'ISO-8859-9'
Too bad I cannot use either encoding to encode innocent
unicode strings
>>> a = unicode('André','latin-1')
>>> print a.encode(locale.getpreferredencoding())
Traceback (most recent call last):
File "", line 1, in ?
LookupError: unknown encoding: ISO-8859-9
>>> print a.encode(locale.getlocale()[1])
Traceback (most recent call last):
File "", line 1, in ?
LookupError: unknown encoding: ISO8859-9
So I take a look at python page and I see that all encoding
names are in lowercase. That's no good, because:
>>> locale.getpreferredencoding().lower()
'\xfdso-8859-9'
(see bug 1193061 )
So I have to do this by hand! But of course this is
unacceptable for any locale aware application.
>>> print a.encode('iso-8859-9')
André
Expected:
1. I expect the encoding string returned by
getpreferredencoding and getlocale to be *identical*
2. I expect the encoding string returned to *work* with
encode method and in general *any* function that accepts
locales.
Got:
1. Different, ad hoc strings
2. Not all aliases present, only lowercases present, no
reliable way to find a canonical locale name.
Recommendations:
a. Please consider the Java-like solution to make Locale
into a class or an enum, something reliable, rather than
just a string.
b. Please test the locale functions in locales other than
US (that is not really a locale anyway)
--
>Comment By: M.-A. Lemburg (lemburg)
Date: 2005-10-24 17:32
Message:
Logged In: YES
user_id=38388
1. The reason why a.encode(locale.getpreferredencoding())
does not work is that the normalization function used by the
codec lookup function uses .lower() to normalize the
encoding string and expects this to happen using the ASCII
mapping of lower case characters - just like many other
places in Python standard library.
2. string.lower() and .upper() are not broken - it's just
that they depend on the GLIBC settings for these mappings.
Python expects -at the very least- to have these GLIBC APIs
map the ASCII characters in their ASCII defined way.
Obviously, this is no longer the case when switching to the
TR_tr locale. I'd consider that a bug in GLIBC - not Python.
A C implementation that maps a captial ASCII I to anything
else than a lower case ASCII i is broken, IMHO. It
certainly is not ASCII compatible and that's one of the few
requirements Python makes regarding the platform.
3. If you want to use gettext, please use the gettext module
- this does not need any of the setlocale() functions.
4. Since you are already using Unicode, I don't really
understand why you want to bother with all the problems that
setlocale() introduces at all ?
You should probably leave setlocale() untouched and instead
use the locale module functions to access various converter
functions, e.g. for numeric values.
--
Comment By: Eray Ozkural (exa)
Date: 2005-10-24 17:08
Message:
Logged In: YES
user_id=1454
I had read your reply very carefully. Had it
made sense, I would think that this bug was
invalid. However, it is not invalid. More
explanation below. Please read carefully.
First, we are not foolish enough to store the text as
8-bit strings in our application. All text is stored as
UTF-8, if that is what you are wondering.
This bug report is wholly concerned with
the question: Why does not the following
function work?
>>> print a.encode(locale.getpreferredencoding())
where a is obviously unicode. What makes
you think it is not unicode? It was indicated
carefully in the original report.
What use is encode(.) function if this is
not supposed to work on _every_ locale? Why
should my glibc have anythi
[ python-Bugs-1336582 ] fileinput device or resource busy error
Bugs item #1336582, was opened at 2005-10-24 17:03
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1336582&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Unicode
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: A. Murat EREN (meren)
Assigned to: M.-A. Lemburg (lemburg)
Summary: fileinput device or resource busy error
Initial Comment:
Fileinput module can't work with the unicode path names
properly.
Here is the reproduction of the error:
---8<---8<---8<---8<---
[EMAIL PROTECTED] /home/meren $ touch myfile
[EMAIL PROTECTED] /home/meren $ python
>>> fn = u'/home/meren/myfile'
>>> type(fn)
>>> import fileinput
>>> for line in fileinput.input(fn, inplace = 1):
... print line
...
Traceback (most recent call last):
File "", line 1, in ?
File "/usr/lib/python2.3/fileinput.py", line 231, in next
line = self.readline()
File "/usr/lib/python2.3/fileinput.py", line 300, in
readline
os.rename(self._filename, self._backupfilename)
OSError: [Errno 16] Device or resource busy
>>>
--->8--->8--->8--->8---
This is happening, because the value of the
self._filename variable is just the first character of
the fn: '/'.
The __init__ method of the FileInput class
(/usr/lib/python2.3/fileinput.py) is the responsible
one about this malfunction. In the __init__ function
it's checking the type of the 'files' variable (in this
case it is fn) for an iteration hack:
---8<---8<---8<---8<---
(...)
def __init__(self, files=None, inplace=0,
backup="", bufsize=0):
if type(files) == type(''):
files = (files,)
(...)
--->8--->8--->8--->8---
When the type of the 'files' variable is unicode, the
value of the 'files' variable is incohorently becoming
into this:
files = [u'/', u'h', u'o', u'm', u'e', u'/', u'm',
u'e', u'r', u'e'
consequently, python is trying to execute
os.rename('/', '/.bak') instead of
os.rename('/home/meren/myfile',
'/home/meren/myfile.bak'). After this function call os
module decides to throw an error, normally..
[1],
(...)
if isinstance(files, basestring):
files = (files,)
(...)
[2]
(...)
if type(files) == type(''):
files = (files,)
(...)
Checking the type of the variable in the __init__
function of the class like [1] is solving the problem
(now we are doing it like [2]).. Also, no backward
compatibility problem appearing with this replacement.
Here is a small patch to show replacement properly:
---8<---8<---8<---8<---
--- fileinput.orig.py 2005-10-24 19:55:53.019413368 +0300
+++ fileinput.py2005-10-24 19:56:19.590373968 +0300
@@ -184,7 +184,7 @@
"""
def __init__(self, files=None, inplace=0,
backup="", bufsize=0):
-if type(files) == type(''):
+if isinstance(files, basestring):
files = (files,)
else:
if files is None:
--->8--->8--->8--->8---
and here is the result of the same operation after this
patch:
---8<---8<---8<---8<---
(...)
os.rename(self._filename, self._backupfilename)
OSError: [Errno 16] Device or resource busy
>>> reload(fileinput)
>>> for line in fileinput.input(fn, inplace = 1):
... print line
...
>>>
--->8--->8--->8--->8---
Sorry for the long explanation,
Thanks in advice..
Ciao.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1336582&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1336623 ] tarfile can't extract some tar archives..
Bugs item #1336623, was opened at 2005-10-24 17:47
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1336623&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: A. Murat EREN (meren)
Assigned to: Nobody/Anonymous (nobody)
Summary: tarfile can't extract some tar archives..
Initial Comment:
Here is a small demo to reproduce the same problem:
-8<-8<-8<-8<---
[EMAIL PROTECTED] /home/meren $ wget
ftp://ftp.sleepycat.com/releases/db.1.85.tar.gz
(...)
100%[>] 270,953 17.13K/sETA 00:00
20:21:09 (15.25 KB/s) - `db.1.85.tar.gz' saved [270,953]
[EMAIL PROTECTED] /home/meren $ file db.1.85.tar.gz
db.1.85.tar.gz: gzip compressed data, from Unix
[EMAIL PROTECTED] /home/meren $ python
>>> tar = tarfile.open("db.1.85.tar.gz", "r:gz")
>>> for tarinfo in tar:
... print tarinfo.name
...
db.1.85
db.1.85/btree
db.1.85/btree/Makefile.inc
db.1.85/btree/bt_close.c
db.1.85/btree/bt_conv.c
db.1.85/btree/bt_debug.c
db.1.85/btree/bt_delete.c
db.1.85/btree/btree.h
db.1.85/btree/bt_get.c
db.1.85/btree/bt_open.c
(...)
>>> for tarinfo in tar:
... tar.extract(tarinfo)
...
>>> Ctrl + D
[EMAIL PROTECTED] /home/meren $ ls db*
db.1.85
db.1.85.tar.gz
[EMAIL PROTECTED] /home/meren $ file db.1.85
db.1.85: empty
[EMAIL PROTECTED] /home/meren $ cat db.1.85
[EMAIL PROTECTED] /home/meren $
->8->8->8->8---
Also this file is extracting with the same result too:
ftp://ftp.linux.org.tr/pub/mirrors/gentoo/distfiles/ncompress-4.2.4.tar.gz
This thing is very rarely happening, but it is
happening. Also, I could extract these archives
properly via the native 'tar' binary..
Thanks in advance,
Ciao.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1336623&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1336623 ] tarfile can't extract some tar archives..
Bugs item #1336623, was opened at 2005-10-24 17:47
Message generated for change (Comment added) made by meren
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1336623&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: A. Murat EREN (meren)
Assigned to: Nobody/Anonymous (nobody)
Summary: tarfile can't extract some tar archives..
Initial Comment:
Here is a small demo to reproduce the same problem:
-8<-8<-8<-8<---
[EMAIL PROTECTED] /home/meren $ wget
ftp://ftp.sleepycat.com/releases/db.1.85.tar.gz
(...)
100%[>] 270,953 17.13K/sETA 00:00
20:21:09 (15.25 KB/s) - `db.1.85.tar.gz' saved [270,953]
[EMAIL PROTECTED] /home/meren $ file db.1.85.tar.gz
db.1.85.tar.gz: gzip compressed data, from Unix
[EMAIL PROTECTED] /home/meren $ python
>>> tar = tarfile.open("db.1.85.tar.gz", "r:gz")
>>> for tarinfo in tar:
... print tarinfo.name
...
db.1.85
db.1.85/btree
db.1.85/btree/Makefile.inc
db.1.85/btree/bt_close.c
db.1.85/btree/bt_conv.c
db.1.85/btree/bt_debug.c
db.1.85/btree/bt_delete.c
db.1.85/btree/btree.h
db.1.85/btree/bt_get.c
db.1.85/btree/bt_open.c
(...)
>>> for tarinfo in tar:
... tar.extract(tarinfo)
...
>>> Ctrl + D
[EMAIL PROTECTED] /home/meren $ ls db*
db.1.85
db.1.85.tar.gz
[EMAIL PROTECTED] /home/meren $ file db.1.85
db.1.85: empty
[EMAIL PROTECTED] /home/meren $ cat db.1.85
[EMAIL PROTECTED] /home/meren $
->8->8->8->8---
Also this file is extracting with the same result too:
ftp://ftp.linux.org.tr/pub/mirrors/gentoo/distfiles/ncompress-4.2.4.tar.gz
This thing is very rarely happening, but it is
happening. Also, I could extract these archives
properly via the native 'tar' binary..
Thanks in advance,
Ciao.
--
>Comment By: A. Murat EREN (meren)
Date: 2005-10-24 18:19
Message:
Logged In: YES
user_id=718263
more examples:
ftp://ftp.porcupine.org/pub/security/portmap_5beta.tar.gz
ftp://ftp.porcupine.org/pub/security/tcp_wrappers_7.6.tar.gz
additionally, the same problem appearing when trying to extract
these archives with the "ark" (yet another kde tool, just a simple
front-end for the tar command. interesting, isn't it).
Ciao.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1336623&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
