Sujet : Re: [ksh93u+m] Performance warning message
De : janis_papanagnou+ng (at) *nospam* hotmail.com (Janis Papanagnou)
Groupes : comp.unix.shellDate : 03. Nov 2024, 19:59:04
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <vg8h5p$g55c$1@dont-email.me>
References : 1 2 3
User-Agent : Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
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 ))