XPost: comp.lang.tcl, comp.unix.shell

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.

--
Just like Donald Trump today, Jesus Christ had a Messiah complex.

And, in fact, the similarities between the two figures are quite striking.
For example, both have a ragtag band of followers, whose faith cannot be shaken.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: comp.lang.tcl, comp.unix.shell

On 04.01.2025 23:14, Kenny McCormack wrote:

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: comp.lang.tcl, comp.unix.shell

In comp.lang.tcl Kenny McCormack <gazelle@shell.xmission.com> wrote:

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: comp.lang.tcl, comp.unix.shell

In comp.unix.shell, Kenny McCormack <gazelle@shell.xmission.com> wrote:

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.

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"

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: comp.lang.tcl, comp.unix.shell

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

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...)

--
The plural of "anecdote" is _not_ "data".

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: comp.lang.tcl, comp.unix.shell

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

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".

--
Pensacola - the thinking man's drink.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: comp.lang.tcl, comp.unix.shell

In article <vlcik4$md8n$1@dont-email.me>, Rich <rich@example.invalid> wrote: >In comp.lang.tcl Kenny McCormack <gazelle@shell.xmission.com> wrote:

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

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...)

--
"He is exactly as they taught in KGB school: an egoist, a liar, but talented - he
knows the mind of the wrestling-loving, under-educated, authoritarian-admiring white male populous."
- Malcolm Nance, p59. -

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: comp.lang.tcl, comp.unix.shell

In article <vld4k2$2jao9$1@news.xmission.com>,
Kenny McCormack <gazelle@shell.xmission.com> wrote:

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

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.

--
The randomly chosen signature file that would have appeared here is more than 4 lines long. As such, it violates one or more Usenet RFCs. In order to remain in compliance with said RFCs, the actual sig can be found at the following URL:
http://user.xmission.com/~gazelle/Sigs/Noam

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: comp.lang.tcl, comp.unix.shell

In article <vld933$2jcih$1@news.xmission.com>,
Kenny McCormack <gazelle@shell.xmission.com> wrote:

In article <vld4k2$2jao9$1@news.xmission.com>,
Kenny McCormack <gazelle@shell.xmission.com> wrote:

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

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.

--
I've learned that people will forget what you said, people will forget
what you did, but people will never forget how you made them feel.

- Maya Angelou -

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: comp.lang.tcl, comp.unix.shell

[ f'up to comp.editors set ]

On 05.01.2025 07:33, Kenny McCormack wrote:

In article <vld4k2$2jao9$1@news.xmission.com>,
Kenny McCormack <gazelle@shell.xmission.com> wrote:

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

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: comp.lang.tcl, comp.unix.shell

On 04 Jan 2025 in comp.editors, Kenny McCormack wrote:

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

--
Joe Makowiec
http://makowiec.org/
Email: http://makowiec.org/contact/?Joe
Usenet Improvement Project: http://twovoyagers.com/improve-usenet.org/

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: comp.lang.tcl, comp.unix.shell

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

I can't help but think that this may be related to your post regarding
time calculation. I had left this quote in my reply:

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".

--
Which of these is the crazier bit of right wing lunacy?
1) We've just had another mass shooting; now is not the time to be talking about gun control.

2) We've just had a massive hurricane; now is not the time to be talking about climate change.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: comp.lang.tcl, comp.unix.shell

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

with <vlcbrr$2ito3$1@news.xmission.com> Kenny McCormack wrote:

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]

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

--
Torvalds' goal for Linux is very simple: World Domination
Stallman's goal for GNU is even simpler: Freedom

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)