Re: Number with sign is read as octal despite a leading 10#

On 7/10/18 6:46 PM, Isaac Marcos wrote: > 2018-07-10 18:12 GMT-04:00 Eduardo Bustamante >: > > On Tue, Jul 10, 2018 at 1:57 PM, Isaac Marcos > mailto:isaacmarcos100...@gmail.com>> wrote: > > Chet Ramey (mailto:chet.ra...@case.edu>>) wrote: > [..] > >

Re: Number with sign is read as octal despite a leading 10#

On 7/10/18 4:57 PM, Isaac Marcos wrote: > Chet Ramey (mailto:chet.ra...@case.edu>>) wrote: > > On 7/10/18 2:48 PM, Isaac Marcos wrote: > >     That is not an integer constant. Integer constants don't begin > with `-'. > > > That makes negative numbers invalid. You need to look at th

INT still propagating to child processes when trapped

Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-unknown-linux-gnu' -DCONF_VENDOR='unknown' -DLOCALEDIR='/usr/share/locale'

Re: Number with sign is read as octal despite a leading 10#

According to Chet, the definition > is the same as the ISO C standard. I'm not sure if there's a public > version of the ISO C standard document, but > http://c0x.coding-guidelines.com/6.4.4.1.html seems to be good enough. > The definition of an "integer constant" in that document does not > includ

Re: Number with sign is read as octal despite a leading 10#

2018-07-10 18:12 GMT-04:00 Eduardo Bustamante : > On Tue, Jul 10, 2018 at 1:57 PM, Isaac Marcos > wrote: > > Chet Ramey () wrote: > [..] > > This is not a serious argument. > [...] > > I don't care. All other shells do this correctly. It makes you the only > one > > wrong. > > > > This is not a s

Re: Number with sign is read as octal despite a leading 10#

On Tue, Jul 10, 2018 at 1:57 PM, Isaac Marcos wrote: > Chet Ramey () wrote: [..] > This is not a serious argument. [...] > I don't care. All other shells do this correctly. It makes you the only one > wrong. > > This is not a serious discussion. Can you keep the discussion civil? I don't get why

Re: Number with sign is read as octal despite a leading 10#

Chet Ramey () wrote: > On 7/10/18 2:48 PM, Isaac Marcos wrote: > > That is not an integer constant. Integer constants don't begin with > `-'. > That makes negative numbers invalid. This is not a serious argument. Because of the difference between an operator and a constant. Unary plus > and

Re: Number with sign is read as octal despite a leading 10#

On 10.7. 18:09, Chet Ramey wrote: On 7/10/18 6:44 AM, Ilkka Virta wrote: I think the problematic case here is when the number comes as input from some program, which might or might not print a leading sign or leading zeroes, but when we know that the number is, in any case, decimal. E.g. 'date'

Re: Number with sign is read as octal despite a leading 10#

On Tue, Jul 10, 2018 at 1:44 PM, Ilkka Virta wrote: > I think the problematic case here is when the number comes as input from > some program, which might or might not print a leading sign or leading > zeroes, but when we know that the number is, in any case, decimal. > > E.g. 'date' prints leadi

Re: Number with sign is read as octal despite a leading 10#

On 7/10/18 11:04 AM, Greg Wooledge wrote: > On Tue, Jul 10, 2018 at 11:00:36AM -0400, Chet Ramey wrote: >> On 7/9/18 9:24 PM, Isaac Marcos wrote: >> >>> Bash Version: 4.4 >>> Patch Level: 12 >>> Release Status: release >>> >>> Description: >>> A value inside an arithmetic expansion is processed as

Re: Number with sign is read as octal despite a leading 10#

On 7/10/18 6:44 AM, Ilkka Virta wrote: > I think the problematic case here is when the number comes as input from > some program, which might or might not print a leading sign or leading > zeroes, but when we know that the number is, in any case, decimal. > > E.g. 'date' prints leading zeroes, whi

Re: Word boundary anchors \< and \> not parsed correctly on the right side of =~

On Tue, Jul 10, 2018 at 10:50:05AM -0400, Chet Ramey wrote: >> […] However, this indicates to me that bash recognizes \< \> as word >> anchors: > No, it doesn't. It indicates that the system's POSIX regular expression > implementation has extensions. >> 3. bash evaluates them correctly when used

Re: Number with sign is read as octal despite a leading 10#

On Tue, Jul 10, 2018 at 11:00:36AM -0400, Chet Ramey wrote: > On 7/9/18 9:24 PM, Isaac Marcos wrote: > > > Bash Version: 4.4 > > Patch Level: 12 > > Release Status: release > > > > Description: > > A value inside an arithmetic expansion is processed as octal despite using > > a 10# preffix. > >

Re: Number with sign is read as octal despite a leading 10#

On 7/9/18 9:24 PM, Isaac Marcos wrote: > Bash Version: 4.4 > Patch Level: 12 > Release Status: release > > Description: > A value inside an arithmetic expansion is processed as octal despite using > a 10# preffix. An integer constant cannot contain a `+'. > > Repeat-By: > $ echo $((10#

Re: Word boundary anchors \< and \> not parsed correctly on the right side of =~

On 7/10/18 9:02 AM, Paulo Marcel Coelho Aragão wrote: > On Tue, Jul 10, 2018 at 08:27:18AM -0400, Greg Wooledge wrote: >> Bash uses ERE (Extended Regular Expressions) here. There is no \< or \> >> in an ERE. >> >> http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap09.html#tag_09_04 >

Re: Word boundary anchors \< and \> not parsed correctly on the right side of =~

On 7/10/18 8:52 AM, Ilkka Virta wrote: > On 10.7. 15:27, Greg Wooledge wrote: >> On Mon, Jul 09, 2018 at 10:46:13PM -0300, marcelpa...@gmail.com wrote: >>> Word boundary anchors \< and \> are not parsed correctly on the right >>> side of a =~ regex match expression. >> >> Bash uses ERE (Extended Re

Re: Word boundary anchors \< and \> not parsed correctly on the right side of =~

On 7/9/18 9:46 PM, marcelpa...@gmail.com wrote: > Bash Version: 4.4 > Patch Level: 19 > Release Status: release > > Description: > Word boundary anchors \< and \> are not parsed correctly on the right side of > a =~ regex match expression. Bash assumes Posix regular expressions (EREs), and tho

Re: Word boundary anchors \< and \> not parsed correctly on the right side of =~

On Tue, Jul 10, 2018 at 09:09:06AM -0400, Greg Wooledge wrote: > In this context, the backslashes serve only to "quote" the less-than > and greater-than signs. It's just like writing > > [[ 'foo bar' =~ "<"foo">" ]] You're absolutely right ! I wasn't looking at it from this angle, but yes, \ i

Re: Word boundary anchors \< and \> not parsed correctly on the right side of =~

On Tue, Jul 10, 2018 at 10:02:34AM -0300, Paulo Marcel Coelho Aragão wrote: > It baffles me that literal \< \> are not evaluated correctly > > paulo:~$ [[ 'foo bar' =~ \ ]] && echo yes || echo no > no In this context, the backslashes serve only to "quote" the less-than and greater-than si

Re: Word boundary anchors \< and \> not parsed correctly on the right side of =~

On Tue, Jul 10, 2018 at 08:27:18AM -0400, Greg Wooledge wrote: > Bash uses ERE (Extended Regular Expressions) here. There is no \< or \> > in an ERE. > > http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap09.html#tag_09_04 Thanks for the reference. The document lists only ^ and $ as

Re: Word boundary anchors \< and \> not parsed correctly on the right side of =~

On 10.7. 15:27, Greg Wooledge wrote: On Mon, Jul 09, 2018 at 10:46:13PM -0300, marcelpa...@gmail.com wrote: Word boundary anchors \< and \> are not parsed correctly on the right side of a =~ regex match expression. Bash uses ERE (Extended Regular Expressions) here. There is no \< or \> in an

Re: Word boundary anchors \< and \> not parsed correctly on the right side of =~

On Mon, Jul 09, 2018 at 10:46:13PM -0300, marcelpa...@gmail.com wrote: > Word boundary anchors \< and \> are not parsed correctly on the right side of > a =~ regex match expression. Bash uses ERE (Extended Regular Expressions) here. There is no \< or \> in an ERE. http://pubs.opengroup.org/onl

Re: Number with sign is read as octal despite a leading 10#

For what it's worth, ksh and zsh seem to interpret 10#-0159 as negative one-hundred and fifty-nine: $ ksh -c 'for a do a="10#$a"; printf "%s " $((a + 1)); done; echo' \ sh +159 +0159 -159 -0159 160 160 -158 -158 $ zsh -c 'for a do a="10#$a"; printf "%s " $((a + 1)); done; echo' \ sh +159 +01

Re: Number with sign is read as octal despite a leading 10#

I think the problematic case here is when the number comes as input from some program, which might or might not print a leading sign or leading zeroes, but when we know that the number is, in any case, decimal. E.g. 'date' prints leading zeroes, which is easy enough to handle: hour=$(date +%H)