The "leading zero means octal" thing...

[Kenny McCormack]

First of all, yes, I know this is all standardized and it is based on
legacy C conventions and it can't be changed and so on and so forth.

But if not a bug, it is certainly a misfeature.

I am referring, of course, to the convention that a number with a leading
zero is interpreted as octal. I can't count the number of times I've been
bitten by this - in various languages/environments all across the Unix
ecosystem. Note the choice of newsgroups above - I have been affected by
this in each of these environments - most recently in Tcl (Expect) and in
the VIM editor.

In fact, the really obnoxious part about it is that it means a number
string like "08" is invalid, because 8 is not a valid digit in octal. I
wish there was a global way to turn this off - some option to set that says
"Don't do that!". I realize, of course, that it has to be on by default,
but it should be possible to turn it off.

Incidentally, and this was my motivation for posting this rant, I hit this
in VIM - where if the cursor is sitting on the zero in a string like Foo07
and you hit ^A, it changes it to - are you ready? - not Foo08, but Foo010.

Totally weird and unexpected.

[Janis Papanagnou]

Post by Kenny McCormack
First of all, yes, I know this is all standardized and it is based on
legacy C conventions and it can't be changed and so on and so forth.
But if not a bug, it is certainly a misfeature.
I am referring, of course, to the convention that a number with a leading
zero is interpreted as octal. I can't count the number of times I've been
bitten by this - in various languages/environments all across the Unix
ecosystem. Note the choice of newsgroups above - I have been affected by
this in each of these environments - most recently in Tcl (Expect) and in
the VIM editor.
In fact, the really obnoxious part about it is that it means a number
string like "08" is invalid, because 8 is not a valid digit in octal. I
wish there was a global way to turn this off - some option to set that says
"Don't do that!". I realize, of course, that it has to be on by default,
but it should be possible to turn it off.
Incidentally, and this was my motivation for posting this rant, I hit this
in VIM - where if the cursor is sitting on the zero in a string like Foo07
and you hit ^A, it changes it to - are you ready? - not Foo08, but Foo010.
Totally weird and unexpected.

Yes.

(You can find this complaint also already mentioned on the Web
in 2012, maybe even before. I suppose it's hard to do or change
anything as default behavior now.)

As a consequence, in Kornshell, I'm using a number prefix 10# to
counter that misbehavior. (I'd suppose this works also in other
major shells like Bash.)

In Vim there's a "sensible.vim" plugin available. (But I've not
tried it.) Given the tons of options in Vim I wonder why they
haven't supported an option to fix it inherently.

Janis

[Kenny McCormack]

In article <vlce6p$lk3q$***@dont-email.me>,
Janis Papanagnou <janis_papanagnou+***@hotmail.com> wrote:
...

Post by Janis Papanagnou
As a consequence, in Kornshell, I'm using a number prefix 10# to
counter that misbehavior. (I'd suppose this works also in other
major shells like Bash.)

Yes, bash has that, too. But for whatever it is worth, in at least one of
my scripts, using it was inconvenient (*), so I ended up having to use "bc" to
do a calculation instead of (the more efficient/built-in) $((...)) (**).
Sort of annoying.

(*) Didn't work out, for some reason.

(**) Which had been working fine right up until it hit the dreaded "08".

[Rich]

Post by Kenny McCormack
I am referring, of course, to the convention that a number with a
leading zero is interpreted as octal. ... most recently in Tcl
(Expect) ...

For Tcl 9, leading zero decimal number strings are no longer
interpreted as octal:

https://www.tcl-lang.com/software/tcltk/9.0.html

Numbers

0NNN format is no longer octal interpretation. Use 0oNNN

[Kenny McCormack]

Post by Rich

Post by Kenny McCormack
I am referring, of course, to the convention that a number with a
leading zero is interpreted as octal. ... most recently in Tcl
(Expect) ...

For Tcl 9, leading zero decimal number strings are no longer
https://www.tcl-lang.com/software/tcltk/9.0.html
Numbers
0NNN format is no longer octal interpretation. Use 0oNNN

This is good news!

I guess I'm going to have to re-compile (A private version of) Tcl and
Expect (one of these days...)

[Eli the Bearded]

Post by Kenny McCormack
First of all, yes, I know this is all standardized and it is based on
legacy C conventions and it can't be changed and so on and so forth.
But if not a bug, it is certainly a misfeature.

I can see it as a legacy feature that has grown so old as to be a
misfeature. Other than bit patterns for chmod, I never see octal used
for modern stuff.

Post by Kenny McCormack
the VIM editor.

Vim is highly configurable. See ":help nrformats" for supported formats.
Not clearly documented in the version I have, but implied, is setting
it to a blank string to only recognize ordinary decimal numbers.

:set nrformats=

If you have no vimrc, the defaults.vim shipped with the editor (vim 8)
sets that to recognize decimal, binary ("0b10101"), and hexadecimal
("0xcafe"). But the compiled in default also includes the dreaded
octal.

You might want to peruse the defaults.vim file for modern recommended
defaults. Except for scrolloff and incsearch, I don't find them that
unpleasant. I think a lot of people like incsearch, and I like scrolloff
on occaison, but not regularly.

Start vim, then ":e $VIMRUNTIME/defaults.vim" to view the defaults file.

Elijah
------
prefers vim acting mostly "compatible"

[Kenny McCormack]

In article <eli$***@qaz.wtf>,
Eli the Bearded <*@eli.users.panix.com> wrote:
...

Post by Eli the Bearded
Vim is highly configurable. See ":help nrformats" for supported formats.
Not clearly documented in the version I have, but implied, is setting
it to a blank string to only recognize ordinary decimal numbers.
:set nrformats=

Thanks for the tip. I'll look into that.

(And note, yes, this interchange between you & me is one of those rare
examples of Usenet working as intended. It gladdens the eye. It makes it
all worthwhile...)

[Kenny McCormack]

Post by Kenny McCormack
...

Post by Eli the Bearded
Vim is highly configurable. See ":help nrformats" for supported formats.
Not clearly documented in the version I have, but implied, is setting
it to a blank string to only recognize ordinary decimal numbers.
:set nrformats=

Thanks for the tip. I'll look into that.

Yes, nf looks good. I set it to "alpha", which makes it do the right thing
with letters, while ignoring the stupid hex/octal/bin stuff.

[Kenny McCormack]

Post by Kenny McCormack

Post by Kenny McCormack
...

Post by Eli the Bearded
Vim is highly configurable. See ":help nrformats" for supported formats.
Not clearly documented in the version I have, but implied, is setting
it to a blank string to only recognize ordinary decimal numbers.
:set nrformats=

Thanks for the tip. I'll look into that.

Yes, nf looks good. I set it to "alpha", which makes it do the right thing
with letters, while ignoring the stupid hex/octal/bin stuff.

And one more thing...

It seems nf is buffer-local, so setting it while in one buffer does not
change it globally. Setting it in .vimrc does set it globally (which makes
sense, since no other buffers exist at that point - and they all inherit
the value).

I get why this is the way it works, but am curious if there is a way to set
it globally (without exiting and re-starting VIM, of course). I have lots
of windows and buffers open and don't want to re-start.

I read "help :set" and it covers a lot, but didn't see anything
specifically on this topic.

[Janis Papanagnou]

[ f'up to comp.editors set ]

Post by Kenny McCormack

Post by Kenny McCormack
...

Post by Eli the Bearded
Vim is highly configurable. See ":help nrformats" for supported formats.
Not clearly documented in the version I have, but implied, is setting
it to a blank string to only recognize ordinary decimal numbers.
:set nrformats=

Thanks for the tip. I'll look into that.

Yes, nf looks good. I set it to "alpha", which makes it do the right thing
with letters, while ignoring the stupid hex/octal/bin stuff.

This 'alpha' is an interesting useful feature I didn't know. Thanks.
(It will go into my .vimrc file.)

Testing it I was a bit astonished, though, that (and different from
numbers) it just works on single letters without a "carry"; with the
string "say38", operating a 66^A on the number part creates "say104"
while at any character it stops increment at "z".

(I recall that I once had a requirement to enumerate some date as
aa, ab, ac, ..., az, ba, bb, ..., bz, ..., zz, and even continuing
zz with aaa, as with a numeric carry.)

Janis

[Joe Makowiec]

I hit this in VIM - where if the cursor is sitting on the zero in a
string like Foo07 and you hit ^A, it changes it to - are you ready?
- not Foo08, but Foo010.

For what it's worth, I tried this in my edition of vim (v 9.1 on
Fedora 41, pretty much default). It incremented Foo07 to Foo08. I dug
into /usr/share/vim/vim91/defaults.vim and found this:

" Do not recognize octal numbers for Ctrl-A and Ctrl-X, most users find it
" confusing.
set nrformats-=octal

[saito]

Post by Kenny McCormack
First of all, yes, I know this is all standardized and it is based on
legacy C conventions and it can't be changed and so on and so forth.
But if not a bug, it is certainly a misfeature.
I am referring, of course, to the convention that a number with a leading
zero is interpreted as octal. I can't count the number of times I've been
bitten by this - in various languages/environments all across the Unix
ecosystem. Note the choice of newsgroups above - I have been affected by
this in each of these environments - most recently in Tcl (Expect) and in
the VIM editor.

I can't help but think that this may be related to your post regarding

Post by Kenny McCormack
There is an interesting "octal" problem left as an exercise 🙂

This was exactly the exercise as well. "clock format" leaves leading
zeros in the result depending on what time it was. It is missing "string
trimleft" calls which I'd discovered after some test runs before posting.

[Kenny McCormack]

In article <vletuv$17djb$***@dont-email.me>, saito <***@gmail.com> wrote:
...

Post by saito
I can't help but think that this may be related to your post regarding

Post by Kenny McCormack
There is an interesting "octal" problem left as an exercise

This was exactly the exercise as well. "clock format" leaves leading
zeros in the result depending on what time it was. It is missing "string
trimleft" calls which I'd discovered after some test runs before posting.

It is, in fact, related to that other thread. In fact, I had developed an
entirely different solution to that problem (very short, in fact) which had
been running fine for a few weeks until it happened to hit the dreaded "08"
and crashed. I fixed that basically by adding code using "regsub" to
remove any leading zero before doing the calculations.

I'll have to take a look at "string trimleft".

[Eric Pozharski]

["Followup-To:" header set to comp.unix.shell.] # because tcl and vim are covered.

Post by Kenny McCormack
First of all, yes, I know this is all standardized and it is based on
legacy C conventions and it can't be changed and so on and so forth.

*CUT* [ 16 lines 1 level deep]

Post by Kenny McCormack
Totally weird and unexpected.

Quick grep through bash.info yelded nothing. But there is hope -- come
to the dark side, zsh has cookies:

% echo $(( 010 - 1 ))
9