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.

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

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

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"

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

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.

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

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

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 -

[ 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

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/

I updated my 'seq' code because of this thread:

https://wiki.tcl-lang.org/page/seq

--
Luc
>>

Luc <luc@sep.invalid> wrote:
> I updated my 'seq' code because of this thread:
>
> https://wiki.tcl-lang.org/page/seq

And, line one of the proc contains the common Tcl bug of "applying a
string operator" to a tcl list.

Note this:

$ rlwrap tclsh
% proc p {args} { set args [string trimleft $args 0] ; return $args }
% p 08
8
% p 08 08
8 08
% p #08 08
{#08} 08
% p 08 0a "one two three"
8 0a {one two three}

The 'args' special variable to a proc is provided to the proc as a
"list".

'string trimleft' is a string operator (not a list operator). So when
'string trimleft' is applied to a list, Tcl first converts the list
into a string, the operates on the string, which will likely not
produce the expected result.

Note the second 'test' above, where 08 08 was passed to p. Because
args was converted to a string, only the initial leading zero was
removed. However it is likely that the intent was to convert 08 08
into 8 and 8. But 'string trimleft' does not work on individual list
elements, it only knows strings, and after [list 08 08] is converted to
a string, string trimleft sees "08 08" and only removes the first 0.

Next, note the third test, where #08 was passed in. It is unlikely the
intent was for #08 to become {#08} (the added {}'s are from Tcl's list
to string conversion).

Note as well the fourth test. "one two three" was changed to {one two
three}. Also not likely the intended outcome.

What this proc likely wanted was to iterate over each element in the
args list, and remove leading zeros from each element, i.e.:

proc p2 {args} { set args [lmap x $args {string trimleft $x 0}] ; return $args }

Which does the right thing for plural leading zero arguments:

% p2 08
8
% p2 08 08
8 8
% p2 08 08 08
8 8 8

Note, because the CLI does a list to string conversion when printing
the return value, we can still get 'weird characters' when showing a
demo:

% p2 #08 08 08 "this or that"
{#08} 8 8 {this or that}

But a simple tweak will show the internal contents of the list without
the extra 'stringification':

% join [p2 #08 08 08 "this or that"] |
#08|8|8|this or that

On 1/4/2025 5:14 PM, 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.
>

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.

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.

On Sun, 5 Jan 2025 21:04:46 -0000 (UTC), Rich wrote:

>Luc <luc@sep.invalid> wrote:
>> I updated my 'seq' code because of this thread:
>>
>> https://wiki.tcl-lang.org/page/seq
>
>And, line one of the proc contains the common Tcl bug of "applying a
>string operator" to a tcl list.

**************************

While I admit that I never took the list to string conversion into
consideration (I am repeat offender at that), you explore certain
possibilities in your exposition that I did take into consideration,
and I decided that those don't matter.

Anyone who has ever used seq (or just merely understands it in spite
of never having used it) knows what the input is supposed to be: two
or three integers.

I improved on it by adding the ability to produce alphabetic sequences.

About your examples, being atypically blunt, no programmer is stupid
enough to input 08 and 08. Even I wouldn't that. Likewise, no programmer
will be stupid enough to input #08. And if anyone actually does that,
they will get the empty string. The code intentionally refuses to
produce output when the input is incorrect.

Of course, we have to consider the possibility of input being generated
by some other code, which makes it more unpredictable. But then the
blame will fall upon the code that produces incorrect input, and
whoever writes (and hopefully tests) such code will have to make sure
that the input is always correct. I can't blame the authors of the
list and string commands to be responsible for my repeated incorrect
use of lists and strings.

But of course I am glad you chimed in once again because I was getting
wrong outputs for '08 08' and '08 09'. I also noted another bug that
you didn't point out: 'p.seq 0 5' was outputting '1 2 3 4 5' without
the zero, which was also incorrect.

So thanks to you, I have updated the code once again.

Thank you.

--
Luc
>>

Luc <luc@sep.invalid> wrote:
> On Sun, 5 Jan 2025 21:04:46 -0000 (UTC), Rich wrote:
>
>>Luc <luc@sep.invalid> wrote:
>>> I updated my 'seq' code because of this thread:
>>>
>>> https://wiki.tcl-lang.org/page/seq
>>
>>And, line one of the proc contains the common Tcl bug of "applying a
>>string operator" to a tcl list.
>
> **************************
>
> While I admit that I never took the list to string conversion into
> consideration (I am repeat offender at that), you explore certain
> possibilities in your exposition that I did take into consideration,
> and I decided that those don't matter.
>
> Anyone who has ever used seq (or just merely understands it in spite
> of never having used it) knows what the input is supposed to be: two
> or three integers.
>
> I improved on it by adding the ability to produce alphabetic sequences.
>
> About your examples, being atypically blunt, no programmer is stupid
> enough to input 08 and 08. Even I wouldn't that. Likewise, no programmer
> will be stupid enough to input #08. And if anyone actually does that,
> they will get the empty string. The code intentionally refuses to
> produce output when the input is incorrect.

And, of course, you miss the forest due to focusing on the trees.

For this trivial example, the list to string conversion is not a "big
deal". The greater point, and the one you should have taken from this,
is that applying string operators willy-nilly to things that are
documented as lists (or that contain lists) creates subtle, data
dependent, bugs that can lie in wait for a very long time before "just
the right data pattern" arrives that triggers the bug. This often
occurs weeks or months (or longer) after one initially wrote the code,
and it has been working perfectly since then, and then mysteriously, it
fails. Those bugs can be very troublesome to track down.

By being careful up front with "string operators" for "strings" and
"list operators" for "lists" you can avoid an entire class of subtle,
surprise, bugs that are hard to track down (even more so after you've
long forgotten why you wrote what you wrote).

Luc <luc@sep.invalid> wrote:
> So thanks to you, I have updated the code once again.

You do know about the "foreach" loop, that specifically iterates across
each element of a list, right?

Even if you don't want to use lmap (which does require 8.6 IIRC) you
don't need a C style "for" loop to iterate a list. Your "for {set x 0}
loop could be something like:

set cleanargs {}
foreach arg $args {
if {[string length $arg] > 1} {
lappend cleanargs [string trimleft $arg 0]
} else {
lappend cleanargs $arg
}
}

Alternately, since you are recreating seq, which only expects numbers
as args, you could do:

set cleanargs {}
foreach arg $args {
lappend cleanargs [scan $arg %d]
}

Which will handle any number of leading zeros (while producing decimal
output) and will error out on non-numeric inputs.

And, if you are willing to use lmap, the above four lines can become
this single line:

set args [lmap arg $args {scan $arg %d}]

Posting groups and followup trimmed as this is Tcl specific:

In comp.lang.tcl Kenny McCormack <gazelle@shell.xmission.com> wrote:
> 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".

The canonical Tcl way to handle decimal number strings with leading
zeros is to filter them through [scan] using the %d scan pattern.

$ rlwrap tclsh
% scan 08 %d
8
% scan 00000000000000000000008 %d
8
%

On Mon, 6 Jan 2025 03:12:48 -0000 (UTC), Rich wrote:

>And, if you are willing to use lmap, the above four lines can become
>this single line:
>
> set args [lmap arg $args {scan $arg %d}]
>
**************************

You are not going to believe this:

I never knew that lmap existed.

I've known lassign for a very long time.
Never knew about lmap until today.

--
Luc
>>

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

Luc <luc@sep.invalid> wrote:
> On Mon, 6 Jan 2025 03:12:48 -0000 (UTC), Rich wrote:
>
>>And, if you are willing to use lmap, the above four lines can become
>>this single line:
>>
>> set args [lmap arg $args {scan $arg %d}]
>>
> **************************
>
> You are not going to believe this:
>
> I never knew that lmap existed.
>
> I've known lassign for a very long time.
> Never knew about lmap until today.

In your defense, it was only introduced with Tcl 8.6, so it is one of
the newer additions.

In article <vlfhs3$1ande$3@dont-email.me>, Rich <rich@example.invalid> wrote:
....
>The canonical Tcl way to handle decimal number strings with leading
>zeros is to filter them through [scan] using the %d scan pattern.
>
> $ rlwrap tclsh
> % scan 08 %d
> 8
> % scan 00000000000000000000008 %d
> 8
> %
>

That's good to know.

--
(Cruz certainly has an odd face) ... it looks like someone sewed pieces of a
waterlogged Reagan mask together at gunpoint ...

http://www.rollingstone.com/politics/news/how-america-made-donald-trump-unstoppable-20160224