Hello people.
Thank you for explanations, examples and sorry for BCC.
While in office, I'm now allowed to use To or CC.
--
iida
>Your bug report
>
>#24800: expr 8.25 seems to treat 0 in character class in paren incorrectly
>
>which was filed against the coreutils package, has been closed.
Hello,
On 10/26/2016 12:15 PM, Paul Eggert wrote:
There's no bug here: "expr E" exits with status 1 if E evaluates to 0, and expressions
like "0 : '\([0-9]\)$'" do evaluate to 0.
Worth mentioning that this is a known "gotcha", explained here:
http://www.pixelbeat.org/docs/coreutils-gotchas.
On 26/10/16 17:15, Paul Eggert wrote:
> There's no bug here: "expr E" exits with status 1 if E evaluates to 0,
> and expressions like "0 : '\([0-9]\)$'" do evaluate to 0.
Yes this is not a bug but is very confusing.
I've updated with this specific example at:
http://www.pixelbeat.org/docs/coreuti
There's no bug here: "expr E" exits with status 1 if E evaluates to 0,
and expressions like "0 : '\([0-9]\)$'" do evaluate to 0.
Hi,
Please don't report bugs via bcc, else they end up assigned to the wrong
package. I've reassigned this to coreutils and am sending this mail so
it appears on the bug-coreutils list.
y-i...@secom.co.jp wrote:
> Hello, coreutils maintainers.
>
> Command expr in version 8.25 of coreutils seems
On 26/10/16 09:30, Francesco Turco wrote:
> On Tue, 2016-10-25 at 19:52 +0100, Pádraig Brady wrote:
>> This seems like the txt file is in DOS format with \r\n line endings.
>> If you remove the --ignore-missing option, are you presented with
>> $'\r' representations in the missing file names?
>> Th
On Tue, 2016-10-25 at 19:52 +0100, Pádraig Brady wrote:
> This seems like the txt file is in DOS format with \r\n line endings.
> If you remove the --ignore-missing option, are you presented with
> $'\r' representations in the missing file names?
> Though when I downloaded the file it was in unix f
