Message ID | 1416976561-1927-1-git-send-email-simon.marchi@ericsson.com |
---|---|
State | Committed |
Headers |
Received: (qmail 20676 invoked by alias); 26 Nov 2014 04:36:08 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: <gdb-patches.sourceware.org> List-Unsubscribe: <mailto:gdb-patches-unsubscribe-##L=##H@sourceware.org> List-Subscribe: <mailto:gdb-patches-subscribe@sourceware.org> List-Archive: <http://sourceware.org/ml/gdb-patches/> List-Post: <mailto:gdb-patches@sourceware.org> List-Help: <mailto:gdb-patches-help@sourceware.org>, <http://sourceware.org/ml/#faqs> Sender: gdb-patches-owner@sourceware.org Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 20642 invoked by uid 89); 26 Nov 2014 04:36:08 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.2 required=5.0 tests=BAYES_00, SPF_SOFTFAIL autolearn=no version=3.3.2 X-HELO: smtp.electronicbox.net Received: from smtp.electronicbox.net (HELO smtp.electronicbox.net) (96.127.255.82) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 26 Nov 2014 04:36:05 +0000 Received: from simark.localdomain (unknown [96.127.221.218]) by smtp.electronicbox.net (Postfix) with ESMTP id BEA57DF37E; Tue, 25 Nov 2014 23:31:28 -0500 (EST) From: Simon Marchi <simon.marchi@ericsson.com> To: gdb-patches@sourceware.org Cc: simon.marchi@polymtl.ca, Simon Marchi <simon.marchi@ericsson.com> Subject: [PATCH 1/3] python extended prompt: Use os.getcwd() instead of os.getcwdu() Date: Tue, 25 Nov 2014 23:35:59 -0500 Message-Id: <1416976561-1927-1-git-send-email-simon.marchi@ericsson.com> X-IsSubscribed: yes |
Commit Message
Simon Marchi
Nov. 26, 2014, 4:35 a.m. UTC
It seems like using os.getcwdu() here is wrong both for Python 2 and Python 3. For Python 2, this returns a 'unicode' object, which tries to get concatenated to a 'str' object in substitute_prompt. The implicit conversion works when the unicode string contains no accent. When it does contain an accent though, displaying the prompt results in the following error: (gdb) set extended-prompt \w ... File "/home/simark/build/binutils-gdb-python2/gdb/data-directory/python/gdb/prompt.py", line 138, in substitute_prompt result += str(cmd(arg)) UnicodeEncodeError: 'ascii' codec can't encode character u'\xe9' in position 49: ordinal not in range(128) When using os.getcwd() instead, it works correctly. I suppose that Python does the necessary decoding internally. For Python 3, this method simply does not exist. It works fine with os.getcwd(). gdb/ChangeLog: * python/lib/gdb/prompt.py (_prompt_pwd): Use os.getcwd() instead of os.getcwdu(). --- gdb/python/lib/gdb/prompt.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Comments
> It seems like using os.getcwdu() here is wrong both for Python 2 and Python 3. > > For Python 2, this returns a 'unicode' object, which tries to get concatenated > to a 'str' object in substitute_prompt. The implicit conversion works when the > unicode string contains no accent. When it does contain an accent though, > displaying the prompt results in the following error: > > (gdb) set extended-prompt \w > ... > File "/home/simark/build/binutils-gdb-python2/gdb/data-directory/python/gdb/prompt.py", line 138, in substitute_prompt > result += str(cmd(arg)) > UnicodeEncodeError: 'ascii' codec can't encode character u'\xe9' in position 49: ordinal not in range(128) > > When using os.getcwd() instead, it works correctly. I suppose that Python does > the necessary decoding internally. > > For Python 3, this method simply does not exist. It works fine with os.getcwd(). > > gdb/ChangeLog: > > * python/lib/gdb/prompt.py (_prompt_pwd): Use os.getcwd() instead of > os.getcwdu(). I'd like to have other people's opinion on this, as I am not sure. I _think_ that the patch is not making things worse for us, while making things a little better in situations as the above. So, based on that, I'd be inclined to apply it. However, I think the long term fix would be, I believe, to switch the entire thing to unicode. With Python3, it's automatic, but with Python2, we might have to add 'u'-s on every piece of string in the module, and also add some conversions here and there. That's why I am thinking that the long term fix should be a blocker for this patch. Thoughts? > --- > gdb/python/lib/gdb/prompt.py | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/gdb/python/lib/gdb/prompt.py b/gdb/python/lib/gdb/prompt.py > index d99f2ea..04adbfb 100644 > --- a/gdb/python/lib/gdb/prompt.py > +++ b/gdb/python/lib/gdb/prompt.py > @@ -21,7 +21,7 @@ import os > > def _prompt_pwd(ignore): > "The current working directory." > - return os.getcwdu() > + return os.getcwd() > > def _prompt_object_attr(func, what, attr, nattr): > """Internal worker for fetching GDB attributes.""" > -- > 2.1.3
> I'd like to have other people's opinion on this, as I am not sure. > > I _think_ that the patch is not making things worse for us, > while making things a little better in situations as the above. > So, based on that, I'd be inclined to apply it. > > However, I think the long term fix would be, I believe, to switch > the entire thing to unicode. With Python3, it's automatic, but > with Python2, we might have to add 'u'-s on every piece of string > in the module, and also add some conversions here and there. > That's why I am thinking that the long term fix should be a blocker > for this patch. > > Thoughts? An eventual switch to use unicode everywhere would certainly undo this patch. However, I don't see the point in leaving the broken code as-is, unless there are imminent plans to make that switch happen. Simon
> > I'd like to have other people's opinion on this, as I am not sure. > > > > I _think_ that the patch is not making things worse for us, > > while making things a little better in situations as the above. > > So, based on that, I'd be inclined to apply it. > > > > However, I think the long term fix would be, I believe, to switch > > the entire thing to unicode. With Python3, it's automatic, but > > with Python2, we might have to add 'u'-s on every piece of string > > in the module, and also add some conversions here and there. > > That's why I am thinking that the long term fix should be a blocker > > for this patch. > > > > Thoughts? > > An eventual switch to use unicode everywhere would certainly undo this > patch. However, I don't see the point in leaving the broken code as-is, > unless there are imminent plans to make that switch happen. That's exactly my thinking. But not being very familiar with this area, and the handling of unicode, I would like to give others an opportunity to jump in. Let's wait another week, and see if we get additional feedback. If not, we'll push the patch.
On 2014-11-29 06:42 AM, Joel Brobecker wrote: >>> I'd like to have other people's opinion on this, as I am not sure. >>> >>> I _think_ that the patch is not making things worse for us, >>> while making things a little better in situations as the above. >>> So, based on that, I'd be inclined to apply it. >>> >>> However, I think the long term fix would be, I believe, to switch >>> the entire thing to unicode. With Python3, it's automatic, but >>> with Python2, we might have to add 'u'-s on every piece of string >>> in the module, and also add some conversions here and there. >>> That's why I am thinking that the long term fix should be a blocker >>> for this patch. >>> >>> Thoughts? >> >> An eventual switch to use unicode everywhere would certainly undo this >> patch. However, I don't see the point in leaving the broken code as-is, >> unless there are imminent plans to make that switch happen. > > That's exactly my thinking. But not being very familiar with this > area, and the handling of unicode, I would like to give others > an opportunity to jump in. Let's wait another week, and see if > we get additional feedback. If not, we'll push the patch. All right, if nothing comes up about this, I'll push it Monday, first thing in the morning, while eating my cereals.
On 2014-12-05 03:36 PM, Simon Marchi wrote: > On 2014-11-29 06:42 AM, Joel Brobecker wrote: >>>> I'd like to have other people's opinion on this, as I am not sure. >>>> >>>> I _think_ that the patch is not making things worse for us, >>>> while making things a little better in situations as the above. >>>> So, based on that, I'd be inclined to apply it. >>>> >>>> However, I think the long term fix would be, I believe, to switch >>>> the entire thing to unicode. With Python3, it's automatic, but >>>> with Python2, we might have to add 'u'-s on every piece of string >>>> in the module, and also add some conversions here and there. >>>> That's why I am thinking that the long term fix should be a blocker >>>> for this patch. >>>> >>>> Thoughts? >>> >>> An eventual switch to use unicode everywhere would certainly undo this >>> patch. However, I don't see the point in leaving the broken code as-is, >>> unless there are imminent plans to make that switch happen. >> >> That's exactly my thinking. But not being very familiar with this >> area, and the handling of unicode, I would like to give others >> an opportunity to jump in. Let's wait another week, and see if >> we get additional feedback. If not, we'll push the patch. > > All right, if nothing comes up about this, I'll push it Monday, first thing > in the morning, while eating my cereals. I just pushed this. Thanks.
diff --git a/gdb/python/lib/gdb/prompt.py b/gdb/python/lib/gdb/prompt.py index d99f2ea..04adbfb 100644 --- a/gdb/python/lib/gdb/prompt.py +++ b/gdb/python/lib/gdb/prompt.py @@ -21,7 +21,7 @@ import os def _prompt_pwd(ignore): "The current working directory." - return os.getcwdu() + return os.getcwd() def _prompt_object_attr(func, what, attr, nattr): """Internal worker for fetching GDB attributes."""