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
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
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
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
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':
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
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)
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):
> 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.
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
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
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,
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
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
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
> 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>
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
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.
>
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
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://ww
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
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
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
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
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
> $
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
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
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
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.
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
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
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
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
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
*/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
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
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
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
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
...@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
[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
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
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
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
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
-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
[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
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
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
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
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
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,
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
55 matches
Mail list logo