bug#66713: Expr substr on plus symbol

Greetings, I'm not sure if this is the intended UNIX/POSIX behaviour, but on: < expr substr a 1 2 , I get: > a , which is right, but on: < expr substr + 1 2 I get: > expr: syntax error: missing argument after ‘2’ On expr "$line_of_text" 1 2, this error is thrown if the line is a simple '+'. A

bug#52873: expr unexpected syntax error

ok I appreciate the explanation. On Wed, 29 Dec 2021 at 20:58, Paul Eggert wrote: > On 12/29/21 12:01, Martin Rixham wrote: > > What nonsense. I want to parse source code. ')' is not an uncommon line > of > > source code. It should work. > > Unfortunately, you're asking for what is in general

bug#52873: expr unexpected syntax error

What nonsense. I want to parse source code. ')' is not an uncommon line of source code. It should work. On Wed, 29 Dec 2021 at 19:52, Paul Eggert wrote: > On 12/29/21 08:31, Davide Brini wrote: > > I think you need to use '+' before the offending token > > Yes. That's a GNU extension. If you

bug#52873: expr unexpected syntax error

On 12/29/21 12:01, Martin Rixham wrote: What nonsense. I want to parse source code. ')' is not an uncommon line of source code. It should work. Unfortunately, you're asking for what is in general impossible. If the left argument of ':' could be any string, then the grammar for 'expr' would

bug#52873: expr unexpected syntax error

On 12/29/21 08:31, Davide Brini wrote: I think you need to use '+' before the offending token Yes. That's a GNU extension. If you want to be portable to any POSIX implementation, you can use this instead: expr "X(" : '.*' - 1 A similar example is given in the POSIX spec for 'expr':

bug#52873: expr unexpected syntax error

On Wed, 29 Dec 2021 12:42:24 +, Martin Rixham wrote: > I'm getting an error from the following: > > [martin@fedora ~]$ expr ')' : '.*' > expr: syntax error: unexpected ')' > > There also seems to be a similar problem with: > > expr '(' : '.*' I think you need to use '+' before

bug#52873: expr unexpected syntax error

I'm getting an error from the following: [martin@fedora ~]$ expr ')' : '.*' expr: syntax error: unexpected ')' There also seems to be a similar problem with: expr '(' : '.*' Here's the version: [martin@fedora ~]$ expr --version expr (GNU coreutils) 8.32 Copyright (C)

bug#22064: expr: expr string : '.*' returns the number of matched bytes not characters

tags 22064 fixed close 22064 stop (triaging old bugs) On 30/11/15 02:09 PM, Stephane Chazelas wrote: that's another multibyte issue, it may be known already but I can't see it being referenced on debbugs.gnu.org. This commit added multibyte support to expr(1):

bug#26779: expr length

> On Jun 28, 2017, at 12:32, Pádraig Brady wrote: > > On 27/06/17 18:41, Assaf Gordon wrote: >> Attached work-in-progress for expr/multibyte, > This looks to have sufficient testing and is ready to push. > We can look at using wide strings internally in a further patch.

bug#26779: expr length

On 27/06/17 18:41, Assaf Gordon wrote: > Hi, > > Attached work-in-progress for expr/multibyte, > hopefully fixing all (most?) of the coding style issues > (Internal conversion to wide strings not yet implemented). > > Comments welcomed, > - assaf > Excellent work. This looks to have

bug#26779: expr length

Hi, Attached work-in-progress for expr/multibyte, hopefully fixing all (most?) of the coding style issues (Internal conversion to wide strings not yet implemented). Comments welcomed, - assaf 0001-expr-add-multibyte-support.patch.gz Description: application/gzip

bug#26779: expr length

Assaf Gordon wrote: The downside of 'mbstowcs' is that it fails and does not continue when it encounters invalid multibyte sequences, It's OK for expr to report an error and exit in that case, which should be simple. It's not a big deal. I fixed the one case I spotted - if I missed any,

bug#26779: expr length

e new multibyte support. I could not find an exact version where this bug was 'introduced'. 'expr' never had a notion of multibyte strings, it was gnulib's "re_match" which gained multibyte support. The earliest gnulib mention of re_match and multibyte I cou

bug#26779: expr length

A couple of things. First, since performance doesn't matter here, wouldn't it be simpler to convert to wide character form by using mbstowcs, do the work in wide-character form, and then convert back via wcstombs? The resulting code should be easier to maintain, I'd think. Also, please stick

bug#26779: expr length

On 09/05/17 00:04, Assaf Gordon wrote: > Hello, > >> On May 4, 2017, at 11:43, Pádraig Brady <p...@draigbrady.com> wrote: >> >> On 04/05/17 02:59, Андрей Воронов wrote: >>> I have the bug in expr utility when it perform operation of the >>> c

bug#26779: expr length

> On May 9, 2017, at 03:04, Assaf Gordon wrote: > > Attached a draft patch implementing multibyte support for 'expr' > (it doesn't need any code from my previous multibyte stuff, so I'm sending it > separately). > [...] > > <0001-expr-add-multibyte-support.patch.gz>

bug#26779: expr length

Hello, > On May 4, 2017, at 11:43, Pádraig Brady <p...@draigbrady.com> wrote: > > On 04/05/17 02:59, Андрей Воронов wrote: >> I have the bug in expr utility when it perform operation of the >> calculating length of the string in my multi-byte encoding ru_RU

bug#26779: expr length

On 04/05/17 02:59, Андрей Воронов wrote: > Hello, > > I have the bug in expr utility when it perform operation of the > calculating length of the string in my multi-byte encoding ru_RU.UTF-8. > When I run: "expr length Привет" > it return me the number 12. >

bug#26779: expr length

Hello, I have the bug in expr utility when it perform operation of the calculating length of the string in my multi-byte encoding ru_RU.UTF-8. When I run: "expr length Привет" it return me the number 12. But in the russian word "Hello" the length is 2 times shorter: e

bug#24800: closed (Re: bug#24800: expr 8.25 seems to treat 0 in character class in paren incorrectly)

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.

bug#24800: expr 8.25 seems to treat 0 in character class in paren incorrectly

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://ww

bug#24800: expr 8.25 seems to treat 0 in character class in paren incorrectly

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: htt

bug#24800: expr 8.25 seems to treat 0 in character class in paren incorrectly

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.

bug#24800: expr 8.25 seems to treat 0 in character class in paren incorrectly

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

bug#22064: expr: expr string : '.*' returns the number of matched bytes not characters

Hello, that's another multibyte issue, it may be known already but I can't see it being referenced on debbugs.gnu.org. $ locale charmap UTF-8 $ expr é : . 2 $ expr é That is, characters are correctly matched, but a number of bytes instead of characters is returned. Same problem with $ expr

bug#22045: expr substr returns with an error code 1 when the substring starts with 0

found with coreutils-8.23, expr substr returns with an error code when the substring consists of only '0' characters, and the match is started at position 1. $ expr substr 1234 3 4; echo $? 0012 0 $ expr substr 1234 1 2; echo $? 12 0 $ expr substr 1234 1 2; echo $? 00 1 $ expr substr

bug#22045: expr substr returns with an error code 1 when the substring starts with 0

tag 22045 notabug close 22045 stop On 28/11/15 20:47, Matthias Klose wrote: > found with coreutils-8.23, expr substr returns with an error code when the > substring consists of only '0' characters, and the match is started at > position 1. > > $ expr substr 1234 3 4; echo $? > 0012 > 0 > $

bug#22045: expr substr returns with an error code 1 when the substring starts with 0

tag 22045 notabug close 22045 stop Hello, On 11/28/2015 03:47 PM, Matthias Klose wrote: found with coreutils-8.23, expr substr returns with an error code when the substring consists of only '0' characters, and the match is started at position 1. $ expr substr 1234 1 4; echo $? 1

bug#11730: bug in expr

hi, i use the following linux distro Linux system name.home 2.6.43.5-2.fc15.i686 #1 SMP Tue May 8 12:07:12 UTC 2012 i686 i686 i386 GNU/Linux the following is the problem $ expr 1 + 1 2 $ expr 1 * 1 expr: syntax error $ _ sorry if it was my mis-understanding of the manual. -- thank you

bug#11730: bug in expr

On Sun, 2012-06-17 at 23:52 +0530, puneeth poduri wrote: 11730 Hi, i use the following linux distro Linux system name.home 2.6.43.5-2.fc15.i686 #1 SMP Tue May 8 12:07:12 UTC 2012 i686 i686 i386 GNU/Linux Version of coreutils (or package you are reporting bug against) is usually more helpful

bug#11730: bug in expr

tags 11730 + notabug close 11730 thanks Ondrej Vasik wrote: This is really your misunderstanding of the shell behaviour. * character is special, it gets expanded by the shell. As this is quite common misunderstanding, it is part of GNU coreutils FAQ.

bug#5812: expr: Difference in behavior of match and :

Thanks Bob for such a nice explanation and your instinct is right. It is locale problem. -bash-3.1$ 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

bug#5812: expr: Difference in behavior of match and :

Adil Mujeeb wrote: Thanks Bob for such a nice explanation and your instinct is right. It is locale problem. ... And the other point you made is also right. I didn’t realize that I was using another session for comparing the result with match which ahs different locale:- I thought it might

bug#5812: expr: Difference in behavior of match and :

tags 5812 + moreinfo unreproducible thanks Adil Mujeeb wrote: I have tried following snippet in a bash script: -bash-3.1$userid=`expr uid=11008(ADILM) gid=1200(cvs),1400(build) : .*uid=[0-9]*(\(.[0-9a-z]*\)) .*` -bash-3.1$echo $userid ADILM -bash-3.1$ To my knowledge it should not

bug#5812: expr: Difference in behavior of match and :

Hello team, I have tried following snippet in a bash script: -bash-3.1$userid=`expr uid=11008(ADILM) gid=1200(cvs),1400(build) : .*uid=[0-9]*(\(.[0-9a-z]*\)) .*` -bash-3.1$echo $userid ADILM -bash-3.1$ To my knowledge it should not able to extract ADILM as the regex does not include uppercase

bug#5812: expr: Difference in behavior of match and :

On 03/31/2010 07:05 AM, Adil Mujeeb wrote: Hello team, I have tried following snippet in a bash script: -bash-3.1$userid=`expr uid=11008(ADILM) gid=1200(cvs),1400(build) : .*uid=[0-9]*(\(.[0-9a-z]*\)) .*` -bash-3.1$echo $userid ADILM -bash-3.1$ I cannot repeat your results with 7.6

Re: Bug in expr***urgent

*/dev/null 21`? The change between '/dev/null' and '1/dev/null' has no effect - they are strictly equivalent in shell programming. You may be benefited by doing more homework on shell programming. But so far, you have failed to show any evidence of a bug in expr. And inserting spurious

Re: Bug in expr***urgent

to upgrade or use other commands like case as you given?The same script is working without any issue in unix expr is more or less stable, but it is ALWAYS a good idea to report bugs against the latest version (if indeed it is a bug in expr). But more likely, the bug is in your script

Re: Auto-discard notification (was Re: Bug in expr***urgent)

On Sat, Jan 16, 2010 at 9:34 PM, Eric Blake e...@byu.net wrote: According to bug-coreutils-boun...@gnu.org on 1/16/2010 12:24 AM: The attached message has been automatically discarded. Subject: Re: Bug in expr

Re: Bug in expr***urgent

to report bugs against the latest version (if indeed it is a bug in expr). But more likely, the bug is in your script, and not expr. -- Don't work too hard, make some time for fun as well! Eric Blake e...@byu.net signature.asc Description: OpenPGP digital signature

Re: Bug in expr***urgent

script is working without any issue in unix expr is more or less stable, but it is ALWAYS a good idea to report bugs against the latest version (if indeed it is a bug in expr). But more likely, the bug is in your script, and not expr. -- Don't work too hard, make some time for fun as well

Re: Bug in expr***urgent

...@gmail.com wrote: Hi, There is a bug iin the expr command and exit status is51198 some times 1552 I have used expr to check whether the variable is numeric add_num=`expr $int_num + 1 1/dev/null 21` kms=$? # if [ $? -ne 0 ] if [ $kms -ne 0 ] then here $kms

Re: Bug in expr***urgent

[your repeated attempts at top-posting when you have been advised not to do so are getting annoying] According to salih k on 1/15/2010 10:17 PM: Hi, 1.Linux 2.6.18-92.el5 #1 SMP Tue Apr 29 13:16:15 EDT 2008 x86_64 2.ksh 3.expr version:5.97 Consider upgrading - the latest stable version of

Bug in expr***urgent

Hi, There is a bug iin the expr command and exit status is51198 some times 1552 I have used expr to check whether the variable is numeric add_num=`expr $int_num + 1 1/dev/null 21` kms=$? # if [ $? -ne 0 ] if [ $kms -ne 0 ] then here $kms returns exit status other

Bug in expr

Hi, I am using CentOS v5.3 BASH v3.2.25(1) and get an error when I use the expr command to extract characters and it encounters a space. It returns the correct value - just sends an error as well. this appears to be a bug # echo $slime three blind mice char=`expr ${slime:4:1}` # echo

Re: Bug in expr

Jay McGuerty wrote: I am using CentOS v5.3 BASH v3.2.25(1) and get an error when I use the expr command to extract characters and it encounters a space. It returns the correct value - just sends an error as well. this appears to be a bug Thanks for the report. However I think this is

bug in expr

Hello! Met with an error. command: expr match ut96_01_200 \([0-9][0-9]_[0-9][0-9]\) did not return, while another command: expr match ut96_01_200 .*\([0-9][0-9]_[0-9][0-9]\) return : 01_20 What should I do to get the desired 96_01 result? Operation System: Fedora 8 x86_64 2.6.25.14-69.fc8

Re: bug in expr

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Dmitry Dobrushin on 11/15/2008 11:41 AM: Hello Dmitry, Thanks for the report; however, this is not a bug. command: expr match ut96_01_200 \([0-9][0-9]_[0-9][0-9]\) did not return, It returned, it just gave the (correct) answer

Re: find a document bug for expr

[EMAIL PROTECTED] wrote: I think I have found a document bug for expr: in the info page of String expressions, it says `expr' supports pattern matching and other string operators. These have *lower* precedence than both the numeric and ...,. But I think the string expressions have *higher

Re: find a document bug for expr

Andreas Schwab [EMAIL PROTECTED] wrote: Jim Meyering [EMAIL PROTECTED] writes: @@ -10884,8 +10884,9 @@ To make @command{expr} interpret keywords as strings, you must use the @cindex expressions, numeric @command{expr} supports the usual numeric operators, in order of increasing

find a document bug for expr

hi, I think I have found a document bug for expr: in the info page of String expressions, it says `expr' supports pattern matching and other string operators. These have *lower* precedence than both the numeric and ...,. But I think the string expressions have *higher* precedence than numeric

Re[2]: possible bug in expr core utils 5.93

Dear Bob, Friday, December 2, 2005, 8:41:17 PM, you wrote: I don't see that. I see this: expr ipsec0=eth0 : '\([^=].*\)=.*' ipsec0 ... This makes be believe it is either related to the locale that you have in your environment or related to the libc regular expression library on your

Re: possible bug in expr core utils 5.93

Serge Leschinsky wrote: Regexp seems to be broken. Thank you for reporting this problem. And thank you for making a nice test case for it. Unfortunately I cannot reproduce this problem on my system and will need more information from you. ++ expr ipsec0=eth0 : '\([^=].*\)=.*' + virt= I

Re: possible bug in expr core utils 5.93

Serge Leschinsky [EMAIL PROTECTED] writes: [EMAIL PROTECTED]:~ # set -x ; IPP=ipsec0=eth0 virt=`expr $IPP : '\([^=].*\)=.*'` echo $virt ; set +x + IPP=ipsec0=eth0 ++ expr ipsec0=eth0 : '\([^=].*\)=.*' + virt= + set +x I don't observe this behavior on my host (Debian stable x86, coreutils 5.93,

Re: Bug in expr?

MONWHEA JENG [EMAIL PROTECTED] wrote: I think there is a bug in expr. When I type expr 2 * 3, I get expr: syntax error. The man page for expr leads me to think that I should get 6. Thanks, but that's not a bug. Your shell is expanding the `*' to a list of all (or most) of the files