Re: [TCLCORE] Fwd: TIP 672 Implementation Complete - Ready for Sponsorship

[Andreas L. <av...@lo...>]

Jan Nijtmans <jan...@gm...> opened my eyes:
> Op do 30 okt 2025 om 02:38 schreef Andreas Leitgeb:
> > If some code contains:    ... [subst -nocommands $userString]
> > then the subst shall never ever cause any command to be called,
> > no matter how it appears in the $userString.
> Are you sure?:
> % set userstring {$a([puts stdout "Command executed"])}
> $a([puts stdout "Command executed"])
> % subst -nocommand $userstring
> Command executed
> can't read "a()": no such variable
> %

Damn.

> From the documentation:
>     Note that the substitution of one kind can include substitution of
>     other kinds. For example, even when the \fB\-novariables\fR option
>     is specified, command substitution is performed without restriction.
>     This means that any variable substitution necessary to complete the
>     command substitution will still take place. Likewise, any command
>     substitution necessary to complete a variable substitution will
>     take place, even when \fB\-nocommands\fR is specified.

I wasn't aware of that...  gotta check my codebase for such 
occurrances and see how I could rewrite them to fix this worm
hole.

I know I used subst recently with both -nocommands and -novars - to
just let it do backslash-treatment.  Does this also have a pathway to
command-subst, or will it have one, if expr turns into a "separate"
thing?

> What we can do is remove the "-noexpression" option, only
> providing the "-expression" option. So, make it off by default.

As I learned, excluding certain substitutions turns out to be a broken
design in the first place. Requiring "-expression" to be explicitly
turned on (rather than off) would probably at least save the current
semantics of [subst -nocommands -novariables $userString], so it causes
least pain among the expr-sensitive alternatives offered so far.

Of course, it is highly confusing to future users of subst, that
some types need excluding, while others need including, so it isn't
really "good design", either.

My lesson for myself is: avoid [subst] altogether.
I might miss the next dicussion about next "new thing", and
suddenly subst even with all previously known -no* options
turns essentially into eval...

Last question: if we get syntactic sugar for expr, is it
technically really not possible to still treat the new syntax
as if it were [expr {...}] for [subst] ?