Re: Case modification fails for Unicode characters
On Thu, Jul 12, 2012 at 2:19 PM, Dennis Williamson
wrote:
> s=łódź; echo "${s^^} ${s~~}"'
> łóDź ŁÓDŹ
>
> The to-upper and the undocumented toggle operators should produce
> identical output in this situation, but only the toggle works
> correctly.
>
> This is in en_US.UTF-8, but also reported in pl_PL.utf-8. In Bash
> 4.2.24 and Bash 4.0.33.
>
> --
> Visit serverfault.com to get your system administration questions answered.
>
I get the same result with:
» echo "$s" | tr '[:lower:]' '[:upper:]'
łóDź
» locale
LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=
This is a locale issue, and has nothing to do with bash itself...
Overflow Bug
Hello, I think I found an overflow bug. I got the follow C program:
#include
#include
int main(int argc, char *argv[])
{
char a[10];
int i;
strcpy(a, argv[1]);
return 0;
}
Compiling with: gcc program.c -o program
And running: program `perl -e 'print "a" x 24'`
The terminal loses the control, entering into a infinite buckle, and
saying: (a variable number here):transferring control: ./programm
I'm on: $uname -a
Linux cosmo 2.6.32-5-amd64 #1 SMP Sun May 6 04:00:17 UTC 2012 x86_64
GNU/Linux
-
Greetings from Argentina.
Ernesto Messina.
Re: Case modification fails for Unicode characters
On Thu, Jul 12, 2012 at 1:57 PM, DJ Mills wrote:
> On Thu, Jul 12, 2012 at 2:19 PM, Dennis Williamson
> wrote:
>> s=łódź; echo "${s^^} ${s~~}"'
>> łóDź ŁÓDŹ
>>
>> The to-upper and the undocumented toggle operators should produce
>> identical output in this situation, but only the toggle works
>> correctly.
>>
>> This is in en_US.UTF-8, but also reported in pl_PL.utf-8. In Bash
>> 4.2.24 and Bash 4.0.33.
>>
>> --
>> Visit serverfault.com to get your system administration questions answered.
>>
>
> I get the same result with:
> » echo "$s" | tr '[:lower:]' '[:upper:]'
> łóDź
>
> » locale
> LANG=en_US.UTF-8
> LC_CTYPE="en_US.UTF-8"
> LC_NUMERIC="en_US.UTF-8"
> LC_TIME="en_US.UTF-8"
> LC_COLLATE="en_US.UTF-8"
> LC_MONETARY="en_US.UTF-8"
> LC_MESSAGES="en_US.UTF-8"
> LC_PAPER="en_US.UTF-8"
> LC_NAME="en_US.UTF-8"
> LC_ADDRESS="en_US.UTF-8"
> LC_TELEPHONE="en_US.UTF-8"
> LC_MEASUREMENT="en_US.UTF-8"
> LC_IDENTIFICATION="en_US.UTF-8"
> LC_ALL=
>
>
> This is a locale issue, and has nothing to do with bash itself...
That's partly true except that ~~ works.
--
Visit serverfault.com to get your system administration questions answered.
Software Developer Required in Mumbai
← D2K Technologies Requires Software Developer Software Developer Required in Mumbai Posted on July 13, 2012 by admin Job Details Area of Work: General / Other Software Industry: IT – Software Location: Mumbai / Navi Mumbai / Thane Job Description Desired Candidate Profile Education: B.Tech /B.E., B.Sc Should have very good knowledge on crystal report, vb.net2.0/3.5, SQL2005, Win forms good communication skill, attitude, handle pressure, willing to travel. Job Description Should be able to design code and integrate the reports. Good understanding of requirement, vb.net2.0/3.5/4.0,Sql2005, crystal report joining in 10days.Office Industry: IT Software, Software Services Location: Mumbai http://www.ways2work.in/software-developer-required-in-mumbai/
Re: Overflow Bug
On Thu, Jul 12, 2012 at 8:09 PM, Ernesto Messina
wrote:
> Hello, I think I found an overflow bug. I got the follow C program:
>
> #include
> #include
>
> int main(int argc, char *argv[])
> {
> char a[10];
> int i;
>
> strcpy(a, argv[1]);
>
> return 0;
> }
>
> Compiling with: gcc program.c -o program
> And running: program `perl -e 'print "a" x 24'`
>
> The terminal loses the control, entering into a infinite buckle, and
bash is not the terminal and is not involved once the program runs,
and yes, writing buggy programs can cause buggy behaviour. On this
system man strcpy says under BUGS:
If the destination string of a strcpy() is not large enough, then any‐
thing might happen. Overflowing fixed-length string buffers is a
favorite cracker technique for taking complete control of the machine.
PS: "infinite loop" not "infinite buckle"
Re: Case modification fails for Unicode characters
On Fri, Jul 13, 2012 at 3:46 AM, Dennis Williamson
wrote:
> On Thu, Jul 12, 2012 at 1:57 PM, DJ Mills wrote:
>> On Thu, Jul 12, 2012 at 2:19 PM, Dennis Williamson
>> wrote:
>>> s=łódź; echo "${s^^} ${s~~}"'
>>> łóDź ŁÓDŹ
>>>
>>> The to-upper and the undocumented toggle operators should produce
>>> identical output in this situation, but only the toggle works
>>> correctly.
>>>
>>> This is in en_US.UTF-8, but also reported in pl_PL.utf-8. In Bash
>>> 4.2.24 and Bash 4.0.33.
>>>
>>> --
>>> Visit serverfault.com to get your system administration questions answered.
>>>
>>
>> I get the same result with:
>> » echo "$s" | tr '[:lower:]' '[:upper:]'
>> łóDź
>>
>> » locale
>> LANG=en_US.UTF-8
>> LC_CTYPE="en_US.UTF-8"
>> LC_NUMERIC="en_US.UTF-8"
>> LC_TIME="en_US.UTF-8"
>> LC_COLLATE="en_US.UTF-8"
>> LC_MONETARY="en_US.UTF-8"
>> LC_MESSAGES="en_US.UTF-8"
>> LC_PAPER="en_US.UTF-8"
>> LC_NAME="en_US.UTF-8"
>> LC_ADDRESS="en_US.UTF-8"
>> LC_TELEPHONE="en_US.UTF-8"
>> LC_MEASUREMENT="en_US.UTF-8"
>> LC_IDENTIFICATION="en_US.UTF-8"
>> LC_ALL=
>>
>>
>> This is a locale issue, and has nothing to do with bash itself...
>
>
> That's partly true except that ~~ works.
>
Also many (all?) versions of tr don't know about locale, eg here:
$ echo ź | tr ź a
aa
