On 25.10.2024 06:46, Janis Papanagnou wrote:

For this command

typeset -i indents=$(( level * indent_factor )) ###

with two integer variables, 'level' and 'indent_factor', declared
I'm getting this nice warning message

warning: line 28: indents=$(( level * indent_factor ))
is slower than ((indents= level * indent_factor ))

I thought (to avoid the warning) I'd have to split the lines like

typeset -i indents
(( indents = level * indent_factor ))

but I noticed that we can also write

(( typeset -i indents = level * indent_factor ))

(I wasn't aware about the 'typeset' command possible in arithmetic expressions.)

Oops! - That's wrong. - I had just tested that only with 'ksh -n'.

ksh -n had produced the above performance warning message, but it
did not produce an error message for the (( typeset ... )) syntax,
which I saw just now when invoking the shell regularly on the code.

This is really odd (shell-)behavior! (Reporting a warning but not
an error.) - Looks like a bug to me.[*]

So we have to either use the "non-performant" syntax marked '###'
or separate the statements on two lines.

Though I wonder why Ksh doesn't silently optimize the '###' marked
code since Ksh optimizes so many less obvious and much more complex
things.

Janis

[*] The man page says for option '-n':
"Read commands and check them for syntax errors, [...]"
So the warning message is just an undocumented feature for free?
And the 'typeset' inside the arithmetic command is syntactically
okay and deserves no diagnostic message?

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

For this command

typeset -i indents=$(( level * indent_factor )) ###

with two integer variables, 'level' and 'indent_factor', declared
I'm getting this nice warning message

warning: line 28: indents=$(( level * indent_factor ))
is slower than ((indents= level * indent_factor ))

I thought (to avoid the warning) I'd have to split the lines like

typeset -i indents
(( indents = level * indent_factor ))

but I noticed that we can also write

(( typeset -i indents = level * indent_factor ))

(I wasn't aware about the 'typeset' command possible in arithmetic expressions.)

Though I wonder why Ksh doesn't silently optimize the '###' marked
code since Ksh optimizes so many less obvious and much more complex
things.

Janis

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

Op 28-10-2024 om 00:21 schreef Janis Papanagnou:

On 25.10.2024 06:46, Janis Papanagnou wrote:

[...]

(( typeset -i indents = level * indent_factor ))

(I wasn't aware about the 'typeset' command possible in arithmetic
expressions.)

Oops! - That's wrong. - I had just tested that only with 'ksh -n'.

ksh -n had produced the above performance warning message, but it
did not produce an error message for the (( typeset ... )) syntax,
which I saw just now when invoking the shell regularly on the code.

This is really odd (shell-)behavior! (Reporting a warning but not
an error.) - Looks like a bug to me.[*]

C-style shell arithmetic is treated as mostly separate from the shell language proper. As far as the shell language is concerned, an arithmetic expansion or command is just a glorified quoted string. So, they are parsed separately from the shell language, and both parsing and executing happens at runtime. This means shell arithmetic syntax errors can only be detected while executing the script, i.e., not when using noexec. All the POSIX-based shells are the same
in that, because they all copied ksh's design for shell arithmetic.

[*] The man page says for option '-n':
"Read commands and check them for syntax errors, [...]"
So the warning message is just an undocumented feature for free?

Yes. The -n (noexec) option activates a (very limited) linter mode that produces certain warnings. The arithmetic-related linter warnings don't look
at the arithmetic expression itself at all, but only at the shell grammar context in which an arithmetic expression is used.

--
|| modernish -- harness the shell
|| https://github.com/modernish/modernish
||
|| KornShell lives!
|| https://github.com/ksh93/ksh

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

On 03.11.2024 18:29, Martijn Dekker wrote:

Op 28-10-2024 om 00:21 schreef Janis Papanagnou:

On 25.10.2024 06:46, Janis Papanagnou wrote:
[...]

C-style shell arithmetic is treated as mostly separate from the shell language proper. As far as the shell language is concerned, an
arithmetic expansion or command is just a glorified quoted string. So,
they are parsed separately from the shell language, and both parsing and executing happens at runtime. This means shell arithmetic syntax errors
can only be detected while executing the script, i.e., not when using
noexec. All the POSIX-based shells are the same in that, because they
all copied ksh's design for shell arithmetic.

[*] The man page says for option '-n':
"Read commands and check them for syntax errors, [...]"
So the warning message is just an undocumented feature for free?

Yes. The -n (noexec) option activates a (very limited) linter mode that produces certain warnings. The arithmetic-related linter warnings don't
look at the arithmetic expression itself at all, but only at the shell grammar context in which an arithmetic expression is used.

Thanks for the background information. - I still find it strange
that structural syntactic errors are not reported but semantical
optimization warnings are. (And, as said, strange that it's not
just optimized away if the shell is even able to detect it.)

I would not have noticed if I hadn't used ksh's option -n that I
anyway use only rarely, so this discrepancy won't have an effect
on my work in practice. - Just thought it might be of interest. -
So never mind.


Concerning the original expression[*] - given that the processing
time is dominated by called processes and I/O and not by built-in
primitive math - I had kept the construct in its "non-performant"
form due to its best readability as an initialized definition.

But it bites in my eyes seeing that 'typeset -i' is declaring an
integer. So pondering about that, and remembering that Kornshell
allows integer variable use in integer contexts without using the
'$' string-value dereferencing, I just tried

typeset -i indents=level*indent_factor

and, what shall I say, it works! And it doesn't trigger a warning
if the shell is called with option '-n'.

Janis

[*] typeset -i indents=$(( level * indent_factor ))

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