From Newsgroup: comp.lang.tcl

As I've mentioned a few times previously, I know very little about TCL and
TCL syntax, even though I've been using (coding in) Expect for many
decades. I've learned what little TCL I need through lots of
trial-and-error and I've asked questions on this NG from time-to-time.

That said, I noticed that the following works as expected:

% puts { This is a string { with embedded curly braces } and it actually works }
This is a string { with embedded curly braces } and it actually works
%

So, it looks like the parser looks inside the outer { } and parses the
inner { } construct. This is good in a way, but is scary, when you start
to consider the possibilities. It means that { } in TCL is not quite as
easy to understand as is the single quote mechanism (known as "strong
quoting") in the shell (sh or bash). In the shell, literally the only
thing that is magic inside of ' is '. And you can always get a ' inside of
a single-quoted string by doing:

$ echo 'Don'\''t do that!'

As far as I can tell, it is not possible to do the analogous thing in TCL.

Note that the following variation on the above does not work:

% puts { This is a string with a right curly brace } that does not work } (error message)
%

I could not figure out how to display the later string in a way that
doesn't error out. So, my question is: How to do that?

Note, BTW:

% puts { This is a string with a right curly brace \} that does work }
This is a string with a right curly brace \} that does work
%

Except that you get that stray backslash in the output - that you
presumably don't want there.
--
A pervert, a racist, and a con man walk into a bar...

Bartender says, "What will you have, Donald!"

--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

Am 18.02.2026 um 13:06 schrieb Kenny McCormack:

As I've mentioned a few times previously, I know very little about TCL and TCL syntax, even though I've been using (coding in) Expect for many
decades. I've learned what little TCL I need through lots of
trial-and-error and I've asked questions on this NG from time-to-time.

That said, I noticed that the following works as expected:

% puts { This is a string { with embedded curly braces } and it actually works }
This is a string { with embedded curly braces } and it actually works
%

So, it looks like the parser looks inside the outer { } and parses the
inner { } construct. This is good in a way, but is scary, when you start
to consider the possibilities. It means that { } in TCL is not quite as
easy to understand as is the single quote mechanism (known as "strong quoting") in the shell (sh or bash). In the shell, literally the only
thing that is magic inside of ' is '. And you can always get a ' inside of
a single-quoted string by doing:

$ echo 'Don'\''t do that!'

As far as I can tell, it is not possible to do the analogous thing in TCL.

Note that the following variation on the above does not work:

% puts { This is a string with a right curly brace } that does not work } (error message)
%

I could not figure out how to display the later string in a way that
doesn't error out. So, my question is: How to do that?

Note, BTW:

% puts { This is a string with a right curly brace \} that does work }
This is a string with a right curly brace \} that does work
%

Except that you get that stray backslash in the output - that you
presumably don't want there.

Kenny,
thanks for the question.
String specifications:
{data} : data is not searched for meta-characters ([]\$)
"data" : any meta-character in data is handled
data : only works, if one tcl-word, otherwise like "data".

So, to represent a string with a non-balanced "{", you need:
puts " This is a string with a right curly brace } that does not work "
In the context of a opened curly brace, like a program fragment, it is necessary to escape the curly brace:

proc a {} {
puts " This is a string with a right curly brace \} that does not work "
}
a
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

Kenny McCormack <gazelle@shell.xmission.com> wrote:

Note that the following variation on the above does not work:

% puts { This is a string with a right curly brace } that does not work } (error message)
%

I could not figure out how to display the later string in a way that
doesn't error out. So, my question is: How to do that?

By changing the starting/ending characters to the " which does
interpret backslash (but also interprets $ and [ too):

$ rlwrap tclsh
% puts " This is a string with a right curly brace \} that does not work "
This is a string with a right curly brace } that does not work

Read this wiki page very carefully, pay special attention to the
portion under the "Rules" heading:

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

The items under the Rules heading fully define Tcl's syntax. But,
fully internalizing them does take some effort.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

* Harald Oehlmann <wortkarg3@yahoo.com>
| So, to represent a string with a non-balanced "{", you need:
| puts " This is a string with a right curly brace } that does not work "
| In the context of a opened curly brace, like a program fragment, it is
| necessary to escape the curly brace:

IMHO escaping an unmatched curly is good practice even in cases where it
is not strictly necessary.

R'
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

On 2/18/2026 11:14 AM, Ralf Fassel wrote:

* Harald Oehlmann <wortkarg3@yahoo.com>
| So, to represent a string with a non-balanced "{", you need:
| puts " This is a string with a right curly brace } that does not work "
| In the context of a opened curly brace, like a program fragment, it is
| necessary to escape the curly brace:

IMHO escaping an unmatched curly is good practice even in cases where it
is not strictly necessary.

Curious. Do you have an example where it is not needed but it doesn't
hurt to use it?

--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

* saito <saitology9@gmail.com>
| On 2/18/2026 11:14 AM, Ralf Fassel wrote:
| > * Harald Oehlmann <wortkarg3@yahoo.com>
| > | So, to represent a string with a non-balanced "{", you need:
| > | puts " This is a string with a right curly brace } that does not work "
| > | In the context of a opened curly brace, like a program fragment, it is
| > | necessary to escape the curly brace:
| > IMHO escaping an unmatched curly is good practice even in cases
| > where it
| > is not strictly necessary.
| >

| Curious. Do you have an example where it is not needed but it doesn't
| hurt to use it?

Both of these are valid TCL code:

1) puts "this is an \{ example"

2) puts "this is an { example"

When I do 'forward-sexp' (i.e. "step over complete expressions")
*inside* the string, emacs complains in 1) "No next sep", wheras it has
no problems stepping over the \{ in 1).

R'
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

* Ralf Fassel <ralfixx@gmx.de>
| * saito <saitology9@gmail.com>
| | On 2/18/2026 11:14 AM, Ralf Fassel wrote:
| | > * Harald Oehlmann <wortkarg3@yahoo.com>
| | > | So, to represent a string with a non-balanced "{", you need:
| | > | puts " This is a string with a right curly brace } that does not work " | | > | In the context of a opened curly brace, like a program fragment, it is | | > | necessary to escape the curly brace:
| | > IMHO escaping an unmatched curly is good practice even in cases
| | > where it
| | > is not strictly necessary.
| | >
| >
| | Curious. Do you have an example where it is not needed but it doesn't
| | hurt to use it?

| Both of these are valid TCL code:

| 1) puts "this is an \{ example"

| 2) puts "this is an { example"

| When I do 'forward-sexp' (i.e. "step over complete expressions")
| *inside* the string, emacs complains in 1) "No next sep", wheras it has

Arghhhh, make that "complains in 2)"

R'
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

Am 18.02.2026 um 17:57 schrieb saito:

On 2/18/2026 11:14 AM, Ralf Fassel wrote:

* Harald Oehlmann <wortkarg3@yahoo.com>
| So, to represent a string with a non-balanced "{", you need:
| puts " This is a string with a right curly brace } that does not work "
| In the context of a opened curly brace, like a program fragment, it is
| necessary to escape the curly brace:

IMHO escaping an unmatched curly is good practice even in cases where it
is not strictly necessary.

Curious. Do you have an example where it is not needed but it doesn't
hurt to use it?

See my example in my post ;-)




--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

On 2/18/2026 12:17 PM, Harald Oehlmann wrote:

Am 18.02.2026 um 17:57 schrieb saito:

On 2/18/2026 11:14 AM, Ralf Fassel wrote:

* Harald Oehlmann <wortkarg3@yahoo.com>
| So, to represent a string with a non-balanced "{", you need:
| puts " This is a string with a right curly brace } that does not
work "
| In the context of a opened curly brace, like a program fragment, it is >>> | necessary to escape the curly brace:

IMHO escaping an unmatched curly is good practice even in cases where it >>> is not strictly necessary.

Curious. Do you have an example where it is not needed but it doesn't
hurt to use it?

See my example in my post ;-)

Right ;-) ?

I think what I meant was "hurts to not use it" but it came out "doesn't
hurt to use it". Silly question either way.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

In article <10n4ic2$2m8ri$3@dont-email.me>, Rich <rich@example.invalid> wrote: >Kenny McCormack <gazelle@shell.xmission.com> wrote:

Note that the following variation on the above does not work:

% puts { This is a string with a right curly brace } that does not work }
(error message)
%

I could not figure out how to display the later string in a way that
doesn't error out. So, my question is: How to do that?

By changing the starting/ending characters to the " which does
interpret backslash (but also interprets $ and [ too):

Actually, I'm quite familiar with using " instead of {, but generally, one should want to use the strong quoting rather than weak quoting. When I
first started using TCL, I tended to use " for strings, primarily because I
was familiar with it from shell. But then I worked out that with ", you
ended up having to escape [ all the time and that gets to be a pain. It is particularly hard to use " when using reg exps, because of the need for quoting.

So, it seems like what you really want is the equivalent of the shell's
single quote (aka, "strong quoting"), where you don't have to quote
anything, except for the single quote itself - where if you want a single quote, you put '\''. So, long and short of this, I was surprised to find
that in TCL, inside of {}, you still have to be careful with } and that, as
far as I can tell, there's no way to do the example shown in the OP.

Yes, I get it that if you switch to using " instead of {}, then the }
problem goes away, but then you have to escape everything else. Ugly.

BTW, I should also note that many of my posts (to various newsgroups and support boards) - including this one - have the form of:

Yes, I have already figured out the answer/workaround, but I'm amazed
and amused that it is the way it is. My question boils down to "Is it
really as whack as I think it is?" and the answer usually ends up being
"Yes".

$ rlwrap tclsh
% puts " This is a string with a right curly brace \} that does not work "
This is a string with a right curly brace } that does not work

Read this wiki page very carefully, pay special attention to the
portion under the "Rules" heading:

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

The items under the Rules heading fully define Tcl's syntax. But,
fully internalizing them does take some effort.

Clearly so. It's weird.
--
If your answer to the question below is any number other than 1, then you're an atheist.

Q: How many religions are worthy of respect? (i.e., how many religions are valid?)
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

Am 18.02.2026 um 18:49 schrieb Kenny McCormack:

In article <10n4ic2$2m8ri$3@dont-email.me>, Rich <rich@example.invalid> wrote:

Kenny McCormack <gazelle@shell.xmission.com> wrote:

Note that the following variation on the above does not work:

% puts { This is a string with a right curly brace } that does not work } >>> (error message)
%

I could not figure out how to display the later string in a way that
doesn't error out. So, my question is: How to do that?

By changing the starting/ending characters to the " which does
interpret backslash (but also interprets $ and [ too):

Actually, I'm quite familiar with using " instead of {, but generally, one should want to use the strong quoting rather than weak quoting. When I
first started using TCL, I tended to use " for strings, primarily because I was familiar with it from shell. But then I worked out that with ", you ended up having to escape [ all the time and that gets to be a pain. It is particularly hard to use " when using reg exps, because of the need for quoting.

So, it seems like what you really want is the equivalent of the shell's single quote (aka, "strong quoting"), where you don't have to quote
anything, except for the single quote itself - where if you want a single quote, you put '\''. So, long and short of this, I was surprised to find that in TCL, inside of {}, you still have to be careful with } and that, as far as I can tell, there's no way to do the example shown in the OP.

Yes, I get it that if you switch to using " instead of {}, then the }
problem goes away, but then you have to escape everything else. Ugly.

BTW, I should also note that many of my posts (to various newsgroups and support boards) - including this one - have the form of:

Yes, I have already figured out the answer/workaround, but I'm amazed
and amused that it is the way it is. My question boils down to "Is it
really as whack as I think it is?" and the answer usually ends up being
"Yes".

$ rlwrap tclsh
% puts " This is a string with a right curly brace \} that does not work " >> This is a string with a right curly brace } that does not work

Read this wiki page very carefully, pay special attention to the
portion under the "Rules" heading:

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

The items under the Rules heading fully define Tcl's syntax. But,
fully internalizing them does take some effort.

Clearly so. It's weird.

Sorry for that.
We are currently trying to change the semantics of "expr {1+1}" to avoid
the curly braces, so to have =1+1
It is hard to change the basement.
The only success here the last 20 years on my radar was the addition of
the delist operator "{*}".

And we will not have soon a major release 10.0 to change internal stuff.
We have survived the 9.0, what was a big effort and step...

Thanks for all,
Harald

--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

On 2/18/2026 9:49 AM, Kenny McCormack wrote:
snip

The items under the Rules heading fully define Tcl's syntax. But,
fully internalizing them does take some effort.

Clearly so. It's weird.

Here's a little gotcha that burned me once and was difficult to find:

puts "here is a string with a \{" ;# this will work here }
if { 1 } {
puts "here is a string with a \{" ;# watch out here }
} else {
puts "can't happen"
}


The puts inside the if block with the ;# comment and a } will fail, while the one at the top will work ok. So, when I had one and later enclosed it inside of an If statement, it failed.

-et



--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

On 2/18/2026 3:56 PM, et99 wrote:

puts "here is a string with a \{" ;# this will work here }
if { 1 } {
-a-a-a-aputs "here is a string with a \{" ;# watch out here }
} else {
-a-a-a-aputs "can't happen"
}

I said that incorrectly. This will fail when it gets to the } else { since the brace in the comment ends the if block and it thinks } else { is a new command.

--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

et99 <et99@rocketship1.me> wrote:

On 2/18/2026 3:56 PM, et99 wrote:

puts "here is a string with a \{" ;# this will work here }
if { 1 } {
-a-a-a-aputs "here is a string with a \{" ;# watch out here }
} else {
-a-a-a-aputs "can't happen"
}

I said that incorrectly. This will fail when it gets to the } else {
since the brace in the comment ends the if block and it thinks } else
{ is a new command.

Yes, because of rule 6:

[6] Braces.
If the first character of a word is an open brace (rCL{rCY) and rule [5]
does not apply, then the word is terminated by the matching close
brace (rCL}rCY). Braces nest within the word: for each additional open
brace there must be an additional close brace (however, if an open
brace or close brace within the word is quoted with a backslash then
it is not counted in locating the matching close brace). No
substitutions are performed on the characters between the braces
except for backslash-newline substitutions described below, nor do
semi-colons, newlines, close brackets, or white space receive any
special interpretation. The word will consist of exactly the
characters between the outer braces, not including the braces
themselves.

"Braces nest within the word: for each additional open brace there must
be an additional close brace (however, if an open brace or close brace
within the word is quoted with a backslash then it is not counted in
locating the matching close brace)."

The parser, seeing a 'word' starting after the closing { 1 } of the if,
begins consuming characters (and counting {} nesting levels, looking
for the closing brace. The double quotes (rule 4) do not yet receive
any special handling, because the brace rule is active for this word,
so they are ignored. The \{ does not count in the bracket nesting due
to the parenthetical part of the quoted section of rule 6. The
semicolon is not special at this point (because we are in a "word" that
began with an opening {, so the next sentence after the quote applies,
the "nor to semi-colons ... receive any special interpretation" part,
so the semi-colon is ignored as special. Which means the # after the semicolon is not at the start of a word, so it is no longer a comment character. So the parser continues until it finds the } at the end of
what was a comment, and that becomes the end of this word.

Then the closing } you intended generates an error because a } should
not appear next.

The issue is we humans are not quite so 'robotic' in our mental parsing
of the same characters and so we forget that the opening { has made
most everything else following "non-special", we see ;# and think
comment, even though this is now not the start of a word, and we expect
the stray } to remain commented out, when it no longer is commented
out.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

Am 19.02.2026 um 01:02 schrieb et99:

On 2/18/2026 3:56 PM, et99 wrote:

puts "here is a string with a \{" ;# this will work here }
if { 1 } {
-a-a-a-a-aputs "here is a string with a \{" ;# watch out here }
} else {
-a-a-a-a-aputs "can't happen"
}

I said that incorrectly. This will fail when it gets to the } else
{ since the brace in the comment ends the if block and it thinks } else
{ is a new command.

Yes, we are sorry for this. TCL does not make any difference between
comments and commands. Due to that, non balances "{" in comments will
change the organisation of your file.

So, the upper snippet is identical to the following code:

if { 1 } {
puts "here is a string with a \{" ;# watch out here
}
} else {
puts "can't happen"
}

This is often hard to understand.
The background is, that there is no difference between code and strings.
And the "{}" do general grouping. They are often handy in programming,
but not necessary.

if " 1 " "
puts "here is a string with a \{" ;# watch out here }
" else "
puts "can't happen"
"

would work in your case. Nevertheless, never do this without clear
reasons, e.g. when you construct program code.
For example:
if $cond $cmdyes else $cmdno

Sorry, it gets complicated....

I just want to say:
- yes, this is on purpose
- there are use-cases (constructed code), where this is quite handy.
Perhaps, others have better examples...

Thanks,
Harald
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

Am 19.02.2026 um 09:53 schrieb Harald Oehlmann:

Am 19.02.2026 um 01:02 schrieb et99:

On 2/18/2026 3:56 PM, et99 wrote:

puts "here is a string with a \{" ;# this will work here }
if { 1 } {
-a-a-a-a-aputs "here is a string with a \{" ;# watch out here }
} else {
-a-a-a-a-aputs "can't happen"
}

I said that incorrectly. This will fail when it gets to the } else
{ since the brace in the comment ends the if block and it thinks }
else { is a new command.

Yes, we are sorry for this. TCL does not make any difference between comments and commands. Due to that, non balances "{" in comments will
change the organisation of your file.

So, the upper snippet is identical to the following code:

if { 1 } {
-a-a-a-a-a puts "here is a string with a \{" ;# watch out here
}
} else {
-a-a-a-a-a puts "can't happen"
}

This is often hard to understand.
The background is, that there is no difference between code and strings.
And the "{}" do general grouping. They are often handy in programming,
but not necessary.

if " 1 " "
-a-a-a puts "here is a string with a \{" ;# watch out here }
" else "
-a-a-a-a-a puts "can't happen"
"

would work in your case. Nevertheless, never do this without clear
reasons, e.g. when you construct program code.
For example:
if $cond $cmdyes else $cmdno

Sorry, it gets complicated....

I just want to say:
- yes, this is on purpose
- there are use-cases (constructed code), where this is quite handy.
Perhaps, others have better examples...

Thanks,
Harald

Sorry, my example was wrong, the " is closed at the string start.
Anyway, others may give examples.
A typical way to construct code is to use a list
set Cmd [list if $cand $cmdyes else $cmdno]
eval $Cmd


--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

On 2/19/2026 1:24 AM, Harald Oehlmann wrote:

Am 19.02.2026 um 09:53 schrieb Harald Oehlmann:

Am 19.02.2026 um 01:02 schrieb et99:

On 2/18/2026 3:56 PM, et99 wrote:

puts "here is a string with a \{" ;# this will work here }
if { 1 } {
-a-a-a-a-aputs "here is a string with a \{" ;# watch out here }
} else {
-a-a-a-a-aputs "can't happen"
}

I said that incorrectly. This will fail when it gets to the } else { since the brace in the comment ends the if block and it thinks } else { is a new command.

Yes, we are sorry for this. TCL does not make any difference between comments and commands. Due to that, non balances "{" in comments will change the organisation of your file.

So, the upper snippet is identical to the following code:

if { 1 } {
-a-a-a-a-a-a puts "here is a string with a \{" ;# watch out here
}
} else {
-a-a-a-a-a-a puts "can't happen"
}

This is often hard to understand.
The background is, that there is no difference between code and strings.
And the "{}" do general grouping. They are often handy in programming, but not necessary.

if " 1 " "
-a-a-a-a puts "here is a string with a \{" ;# watch out here }
" else "
-a-a-a-a-a-a puts "can't happen"
"

would work in your case. Nevertheless, never do this without clear reasons, e.g. when you construct program code.
For example:
if $cond $cmdyes else $cmdno

Sorry, it gets complicated....

I just want to say:
- yes, this is on purpose
- there are use-cases (constructed code), where this is quite handy.
Perhaps, others have better examples...

Thanks,
Harald

Sorry, my example was wrong, the " is closed at the string start.
Anyway, others may give examples.
A typical way to construct code is to use a list
set Cmd [list if $cand $cmdyes else $cmdno]
eval $Cmd

Overall, the advantages of tcl's syntax is well worth the occasional difficulties. I have learned to just avoid braces and brackets in comments and often use substitution such as,

set qt "\""

and use $qt rather than try to construct literal strings with embedded quotes. Similarly for braces and brackets.

My editor let's me create macros where I can select any number of lines and surround them with control structures, such as if, while, if-catch, if-0 etc. It can highlight and/or move to the match for any bracketing pair, and understands \ escape. But using an odd number with these pairs can confuse it, so that's another reason to avoid them even if Tcl doesn't mind.

-et

--- Synchronet 3.21b-Linux NewsLink 1.2