Re: [PATCH] Unexport LANG env variable

[Masahiro Yamada]

Hi Alexey,


2017-06-14 22:11 GMT+09:00 Alexey Brodkin :
> Hi Michal,
>
> On Wed, 2017-06-14 at 15:02 +0200, Michal Marek wrote:
>> Dne 14.6.2017 v 14:40 Alexey Brodkin napsal(a):
>> >
>> > In those cases when we parse output of standard utilities like readelf
>> > etc we rely on a particular sentences. For example for ARC we extract
>> > an entry-point from vmlinux like that:
>> > -->8
>> > readelf -h vmlinux | grep "Entry point address" | grep -o 0x.*
>> > -->8
>> >
>> > And in case LANG is set to anything other than en_XX we're getting
>> > nothing and subsequent execution of mkimage utility fails.
>> >
>> > Probably there're more cases like that but given people rarely
>> > use non-English locales on their dev machines problems like the one
>> > above are not very visible.
>>
>> I'm all for this change but the *.po files in the gcc tree must have
>> been created for a reason:
>>
>>   
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_gcc-2Dmirror_gcc_tree_master_gcc_po=DwICBA=DPL6_X_6JkXFx7AXWqB0tg=lqdeeSSEes
>> 0GFDDl656eViXO7breS55ytWkhpk5R81I=v2ilYYv6Z0WzVaIys3sCQdK3QBI9gqH7hUmoTGPpJ44=S3B79SHovtt1-wLRtngTUM0dKWMiokGE75HIrfgkbbc=
>
> That's for sure.
>
> But then how may we have a predictable environment for our machinery?
>
> I do realize that with that change in place people will start seeing
> non-translated messages from other tools like compiler etc.
>
> But probably that's not the worst idea as well because it helps googling :)


I do not want to lose users' freedom to choose their favorite language.


For example, arch/powerpc/boot/wrapper  does this

LANG=C elfformat="`${CROSS}objdump -p "$kernel" | grep 'file format' |
awk '{print $4}'`"


I think you can solve your problem like that.


-- 
Best Regards
Masahiro Yamada

Re: [PATCH] Unexport LANG env variable

[Masahiro Yamada]

Hi Alexey,


2017-06-14 22:11 GMT+09:00 Alexey Brodkin :
> Hi Michal,
>
> On Wed, 2017-06-14 at 15:02 +0200, Michal Marek wrote:
>> Dne 14.6.2017 v 14:40 Alexey Brodkin napsal(a):
>> >
>> > In those cases when we parse output of standard utilities like readelf
>> > etc we rely on a particular sentences. For example for ARC we extract
>> > an entry-point from vmlinux like that:
>> > -->8
>> > readelf -h vmlinux | grep "Entry point address" | grep -o 0x.*
>> > -->8
>> >
>> > And in case LANG is set to anything other than en_XX we're getting
>> > nothing and subsequent execution of mkimage utility fails.
>> >
>> > Probably there're more cases like that but given people rarely
>> > use non-English locales on their dev machines problems like the one
>> > above are not very visible.
>>
>> I'm all for this change but the *.po files in the gcc tree must have
>> been created for a reason:
>>
>>   
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_gcc-2Dmirror_gcc_tree_master_gcc_po=DwICBA=DPL6_X_6JkXFx7AXWqB0tg=lqdeeSSEes
>> 0GFDDl656eViXO7breS55ytWkhpk5R81I=v2ilYYv6Z0WzVaIys3sCQdK3QBI9gqH7hUmoTGPpJ44=S3B79SHovtt1-wLRtngTUM0dKWMiokGE75HIrfgkbbc=
>
> That's for sure.
>
> But then how may we have a predictable environment for our machinery?
>
> I do realize that with that change in place people will start seeing
> non-translated messages from other tools like compiler etc.
>
> But probably that's not the worst idea as well because it helps googling :)


I do not want to lose users' freedom to choose their favorite language.


For example, arch/powerpc/boot/wrapper  does this

LANG=C elfformat="`${CROSS}objdump -p "$kernel" | grep 'file format' |
awk '{print $4}'`"


I think you can solve your problem like that.


-- 
Best Regards
Masahiro Yamada

Re: [PATCH] Unexport LANG env variable

[Alexey Brodkin]

Hi Michal,

On Wed, 2017-06-14 at 15:02 +0200, Michal Marek wrote:
> Dne 14.6.2017 v 14:40 Alexey Brodkin napsal(a):
> > 
> > In those cases when we parse output of standard utilities like readelf
> > etc we rely on a particular sentences. For example for ARC we extract
> > an entry-point from vmlinux like that:
> > -->8
> > readelf -h vmlinux | grep "Entry point address" | grep -o 0x.*
> > -->8
> > 
> > And in case LANG is set to anything other than en_XX we're getting
> > nothing and subsequent execution of mkimage utility fails.
> > 
> > Probably there're more cases like that but given people rarely
> > use non-English locales on their dev machines problems like the one
> > above are not very visible.
> 
> I'm all for this change but the *.po files in the gcc tree must have
> been created for a reason:
> 
>   
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_gcc-2Dmirror_gcc_tree_master_gcc_po=DwICBA=DPL6_X_6JkXFx7AXWqB0tg=lqdeeSSEes
> 0GFDDl656eViXO7breS55ytWkhpk5R81I=v2ilYYv6Z0WzVaIys3sCQdK3QBI9gqH7hUmoTGPpJ44=S3B79SHovtt1-wLRtngTUM0dKWMiokGE75HIrfgkbbc=
>  

That's for sure.

But then how may we have a predictable environment for our machinery?

I do realize that with that change in place people will start seeing
non-translated messages from other tools like compiler etc.

But probably that's not the worst idea as well because it helps googling :)

-Alexey

Re: [PATCH] Unexport LANG env variable

[Alexey Brodkin]

Hi Michal,

On Wed, 2017-06-14 at 15:02 +0200, Michal Marek wrote:
> Dne 14.6.2017 v 14:40 Alexey Brodkin napsal(a):
> > 
> > In those cases when we parse output of standard utilities like readelf
> > etc we rely on a particular sentences. For example for ARC we extract
> > an entry-point from vmlinux like that:
> > -->8
> > readelf -h vmlinux | grep "Entry point address" | grep -o 0x.*
> > -->8
> > 
> > And in case LANG is set to anything other than en_XX we're getting
> > nothing and subsequent execution of mkimage utility fails.
> > 
> > Probably there're more cases like that but given people rarely
> > use non-English locales on their dev machines problems like the one
> > above are not very visible.
> 
> I'm all for this change but the *.po files in the gcc tree must have
> been created for a reason:
> 
>   
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_gcc-2Dmirror_gcc_tree_master_gcc_po=DwICBA=DPL6_X_6JkXFx7AXWqB0tg=lqdeeSSEes
> 0GFDDl656eViXO7breS55ytWkhpk5R81I=v2ilYYv6Z0WzVaIys3sCQdK3QBI9gqH7hUmoTGPpJ44=S3B79SHovtt1-wLRtngTUM0dKWMiokGE75HIrfgkbbc=
>  

That's for sure.

But then how may we have a predictable environment for our machinery?

I do realize that with that change in place people will start seeing
non-translated messages from other tools like compiler etc.

But probably that's not the worst idea as well because it helps googling :)

-Alexey

Re: [PATCH] Unexport LANG env variable

[Michal Marek]

Dne 14.6.2017 v 14:40 Alexey Brodkin napsal(a):
> In those cases when we parse output of standard utilities like readelf
> etc we rely on a particular sentences. For example for ARC we extract
> an entry-point from vmlinux like that:
> -->8
> readelf -h vmlinux | grep "Entry point address" | grep -o 0x.*
> -->8
> 
> And in case LANG is set to anything other than en_XX we're getting
> nothing and subsequent execution of mkimage utility fails.
> 
> Probably there're more cases like that but given people rarely
> use non-English locales on their dev machines problems like the one
> above are not very visible.

I'm all for this change but the *.po files in the gcc tree must have
been created for a reason:

  https://github.com/gcc-mirror/gcc/tree/master/gcc/po

:)

Michal

Re: [PATCH] Unexport LANG env variable

[Michal Marek]

Dne 14.6.2017 v 14:40 Alexey Brodkin napsal(a):
> In those cases when we parse output of standard utilities like readelf
> etc we rely on a particular sentences. For example for ARC we extract
> an entry-point from vmlinux like that:
> -->8
> readelf -h vmlinux | grep "Entry point address" | grep -o 0x.*
> -->8
> 
> And in case LANG is set to anything other than en_XX we're getting
> nothing and subsequent execution of mkimage utility fails.
> 
> Probably there're more cases like that but given people rarely
> use non-English locales on their dev machines problems like the one
> above are not very visible.

I'm all for this change but the *.po files in the gcc tree must have
been created for a reason:

  https://github.com/gcc-mirror/gcc/tree/master/gcc/po

:)

Michal

[PATCH] Unexport LANG env variable

[Alexey Brodkin]

In those cases when we parse output of standard utilities like readelf
etc we rely on a particular sentences. For example for ARC we extract
an entry-point from vmlinux like that:
-->8
readelf -h vmlinux | grep "Entry point address" | grep -o 0x.*
-->8

And in case LANG is set to anything other than en_XX we're getting
nothing and subsequent execution of mkimage utility fails.

Probably there're more cases like that but given people rarely
use non-English locales on their dev machines problems like the one
above are not very visible.

Signed-off-by: Alexey Brodkin 
Cc: Vineet Gupta 
---
 Makefile | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Makefile b/Makefile
index cdaa747f2a6a..581e684783ef 100644
--- a/Makefile
+++ b/Makefile
@@ -17,6 +17,7 @@ MAKEFLAGS += -rR --include-dir=$(CURDIR)
 
 # Avoid funny character set dependencies
 unexport LC_ALL
+unexport LANG
 LC_COLLATE=C
 LC_NUMERIC=C
 export LC_COLLATE LC_NUMERIC
-- 
2.7.5

[PATCH] Unexport LANG env variable

[Alexey Brodkin]

In those cases when we parse output of standard utilities like readelf
etc we rely on a particular sentences. For example for ARC we extract
an entry-point from vmlinux like that:
-->8
readelf -h vmlinux | grep "Entry point address" | grep -o 0x.*
-->8

And in case LANG is set to anything other than en_XX we're getting
nothing and subsequent execution of mkimage utility fails.

Probably there're more cases like that but given people rarely
use non-English locales on their dev machines problems like the one
above are not very visible.

Signed-off-by: Alexey Brodkin 
Cc: Vineet Gupta 
---
 Makefile | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Makefile b/Makefile
index cdaa747f2a6a..581e684783ef 100644
--- a/Makefile
+++ b/Makefile
@@ -17,6 +17,7 @@ MAKEFLAGS += -rR --include-dir=$(CURDIR)
 
 # Avoid funny character set dependencies
 unexport LC_ALL
+unexport LANG
 LC_COLLATE=C
 LC_NUMERIC=C
 export LC_COLLATE LC_NUMERIC
-- 
2.7.5