From Newsgroup: comp.lang.tcl

Hi,

I admit that I'm fairly undisciplined about whether I write

set var "A string with spaces"

or

set var {A string with spaces}

I have always thought it made no difference. All of a sudden it matters
to me - my code has written a string delimited by quotes to a SQLite
database. I'm trying to test the code and am passing strings to a proc
that checks them against what is in the db. The comparison fails because
the proc expects, say {Some string} but the database query is returning
"Some string" so the proc is correctly detecting a difference.

I was very surprised by this because I was passing "Some string" to the
proc.

Here is a pretty minimal command-line example:

$ echo 'proc test {args} {puts stdout $args}; test "Foo garp"' | tclsh
{Foo garp}

Also

$ echo 'proc test {args} {puts stdout $args}; test {Foo garp}' | tclsh
{Foo garp}

As far as I can see my options are

a) Ensure that the comparison proc in the test script sees a quote-
delimited string;
b) Within the comparision proc, convert the the brace-delimited
string to one that's delimited by quotes;
c) Work out how my code manages to write a quote-delimited string to
the database and get it to write one delimited by quotes instead;
d) Give up on this particular test.

I have no idea how to do either a) or b), c) is going to be a lot of
hard work (and is therefore unappealing :-) ) and d) really feels like
the wrong thing to do.


Alan
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

In article <109q8c9$18m1k$[email protected]>,
Alan Grunwald <[email protected]> wrote:

Hi,

I admit that I'm fairly undisciplined about whether I write

set var "A string with spaces"

or

set var {A string with spaces}

I have always thought it made no difference. All of a sudden it matters

It doesn't.

Here is a pretty minimal command-line example:

$ echo 'proc test {args} {puts stdout $args}; test "Foo garp"' | tclsh
{Foo garp}

The name "args" is special and is a list.

Consider this little file and what it outputs:

==== CUT ===
#!/usr/bin/env tclsh8.6

proc test1 {args} {
puts stdout $args
}

proc test2 {x} {
puts stdout $x
}

test1 {foo bar}
test2 {foo bar}

==== END ===
--
columbiaclosings.com
What's not in Columbia anymore..
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

On 9/9/2025 3:04 PM, Alan Grunwald wrote:

Hi,

I admit that I'm fairly undisciplined about whether I write

set var "A string with spaces"

or

set var {A string with spaces}

I have always thought it made no difference. All of a sudden it matters to me - my code has written a string delimited by quotes to a SQLite database. I'm trying to test the code and am passing strings to a proc that checks them against what is in the db. The comparison fails because the proc expects, say {Some string} but the database query is returning "Some string" so the proc is correctly detecting a difference.

I was very surprised by this because I was passing "Some string" to the proc.

Here is a pretty minimal command-line example:

$ echo 'proc test {args} {puts stdout $args}; test "Foo garp"' | tclsh
{Foo garp}

Also

$ echo 'proc test {args} {puts stdout $args}; test {Foo garp}' | tclsh
{Foo garp}

As far as I can see my options are

a)     Ensure that the comparison proc in the test script sees a quote-
   delimited string;
b)     Within the comparision proc, convert the the brace-delimited
   string to one that's delimited by quotes;
c)     Work out how my code manages to write a quote-delimited string to
   the database and get it to write one delimited by quotes instead; d)     Give up on this particular test.

I have no idea how to do either a) or b), c) is going to be a lot of hard work (and is therefore unappealing :-) ) and d) really feels like the wrong thing to do.

Alan

Generally the rule is:

The quoting only exists at the SQL level:

Going in: Tcl → SQLite interface adds quotes → SQLite receives quoted SQL Coming out: SQLite → SQLite interface removes quotes → Tcl receives plain strings

Exception - if you explicitly store quote characters in your strings.


So, perhaps you can provide a smallish copy/paste example where you are having the problem.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

Alan Grunwald <[email protected]> wrote:

Hi,

I admit that I'm fairly undisciplined about whether I write

set var "A string with spaces"

or

set var {A string with spaces}

I have always thought it made no difference. All of a sudden it matters
to me - my code has written a string delimited by quotes to a SQLite

Please be less ambigious. Is the string delimited by quotes (") or do
you actually mean it is delimited by braces ({) but you say "quotes"?

If what you got in the sqlite db was {a string with spaces} then the
most likely cause was you used a variable containing a list in a string context, in which case you'll get braces added (sometimes) when Tcl
converts the list to a "string representation".

I.e., you've likely mixed together strings and lists and are seeing the "stringified list" in the sqlite db.

$ rlwrap tclsh
% proc test {args} {puts $args}

'args' here inside the proc is actually a list. The "puts $args" is
using a "list" in a "string context", so Tcl outputs the string
representation of the list. Which, as you see below, results in added
braces sometimes:

% test abc
abc
% test "abc def"
{abc def}
%

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

On 09/09/2025 23:28, et99 wrote:

On 9/9/2025 3:04 PM, Alan Grunwald wrote:

Hi,

I admit that I'm fairly undisciplined about whether I write

set var "A string with spaces"

or

set var {A string with spaces}

I have always thought it made no difference. All of a sudden it
matters to me - my code has written a string delimited by quotes to a
SQLite database. I'm trying to test the code and am passing strings to
a proc that checks them against what is in the db. The comparison
fails because the proc expects, say {Some string} but the database
query is returning "Some string" so the proc is correctly detecting a
difference.

I was very surprised by this because I was passing "Some string" to
the proc.

Here is a pretty minimal command-line example:

$ echo 'proc test {args} {puts stdout $args}; test "Foo garp"' | tclsh
{Foo garp}

Also

$ echo 'proc test {args} {puts stdout $args}; test {Foo garp}' | tclsh
{Foo garp}

As far as I can see my options are

a)     Ensure that the comparison proc in the test script sees a quote- >>     delimited string;
b)     Within the comparision proc, convert the the brace-delimited
    string to one that's delimited by quotes;
c)     Work out how my code manages to write a quote-delimited string to >>     the database and get it to write one delimited by quotes instead;
d)     Give up on this particular test.

I have no idea how to do either a) or b), c) is going to be a lot of
hard work (and is therefore unappealing :-) ) and d) really feels like
the wrong thing to do.


Alan

Generally the rule is:

The quoting only exists at the SQL level:

Going in: Tcl → SQLite interface adds quotes → SQLite receives quoted SQL Coming out: SQLite → SQLite interface removes quotes → Tcl receives plain strings

Exception - if you explicitly store quote characters in your strings.

So, perhaps you can provide a smallish copy/paste example where you are having the problem.

Thanks.

I'm busy most of today but will get back to you later on - probably
10-12 hours time.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

On 09/09/2025 23:25, Ted Nolan <tednolan> wrote:

In article <109q8c9$18m1k$[email protected]>,
Alan Grunwald <[email protected]> wrote:

Hi,

I admit that I'm fairly undisciplined about whether I write

set var "A string with spaces"

or

set var {A string with spaces}

I have always thought it made no difference. All of a sudden it matters

It doesn't.

Here is a pretty minimal command-line example:

$ echo 'proc test {args} {puts stdout $args}; test "Foo garp"' | tclsh
{Foo garp}

The name "args" is special and is a list.

Consider this little file and what it outputs:

==== CUT ===
#!/usr/bin/env tclsh8.6

proc test1 {args} {
puts stdout $args
}

proc test2 {x} {
puts stdout $x
}

test1 {foo bar}
test2 {foo bar}

==== END ===

Thanks Ted.

I'm busy most of today but I will get back to you later on - probably
10-12 hours time.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

On 10/09/2025 08:43, Alan Grunwald wrote:

On 09/09/2025 23:25, Ted Nolan <tednolan> wrote:

In article <109q8c9$18m1k$[email protected]>,
Alan Grunwald  <[email protected]> wrote:

Hi,

I admit that I'm fairly undisciplined about whether I write

set var "A string with spaces"

or

set var {A string with spaces}

I have always thought it made no difference. All of a sudden it matters

It doesn't.

Here is a pretty minimal command-line example:

$ echo 'proc test {args} {puts stdout $args}; test "Foo garp"' | tclsh
{Foo garp}

The name "args" is special and is a list.

Consider this little file and what it outputs:

==== CUT ===
#!/usr/bin/env tclsh8.6

proc test1 {args} {
         puts stdout $args
}

proc test2 {x} {
         puts stdout $x
}

test1 {foo bar}
test2 {foo bar}

==== END ===

Thanks Ted.

I'm busy most of today but I will get back to you later on - probably
10-12 hours time.

Sorry Ted - I'm hurrying to get off three replies while I have a moment
and I screwed up. Here's what I meant to say...

I'm pretty sure I have a genuine problem and when I found something that seemed to illustrate it, I became overexcited. When I change my little
example to a more correct

$ echo 'proc test {args} {foreach arg $args {puts stdout $arg}}; test a
b c' | tclsh
a
b
c

and run the original two examples, I get

$ echo 'proc test {args} {foreach arg $args {puts stdout $arg}}; test
{Foo garp}' | tclsh
Foo garp

and

$ echo 'proc test {args} {foreach arg $args {puts stdout $arg}}; test
"Foo garp"' | tclsh
Foo garp

In other words, everything works exactly as I expect.

Alan
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

On 10/09/2025 04:22, Rich wrote:

Alan Grunwald <[email protected]> wrote:

Hi,

I admit that I'm fairly undisciplined about whether I write

set var "A string with spaces"

or

set var {A string with spaces}

I have always thought it made no difference. All of a sudden it matters
to me - my code has written a string delimited by quotes to a SQLite

Please be less ambigious. Is the string delimited by quotes (") or do
you actually mean it is delimited by braces ({) but you say "quotes"?

If what you got in the sqlite db was {a string with spaces} then the
most likely cause was you used a variable containing a list in a string context, in which case you'll get braces added (sometimes) when Tcl
converts the list to a "string representation".

I.e., you've likely mixed together strings and lists and are seeing the "stringified list" in the sqlite db.

$ rlwrap tclsh
% proc test {args} {puts $args}

'args' here inside the proc is actually a list. The "puts $args" is
using a "list" in a "string context", so Tcl outputs the string representation of the list. Which, as you see below, results in added
braces sometimes:

% test abc
abc
% test "abc def"
{abc def}
%

Thanks for the reply Rich. As I said on other messages, I can't give you
a proper response, but I'll get back to you properly later in the day.

I'm pretty sure that I've written a string to the database with real double-quotes ("). I should be able to produce a one-liner command-line
to extract it from the database, but had written that db to /tmp and
it's gone away after an overnight reboot, and I can reproduce the
database right now...


Alan
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl


Alan Grunwald <[email protected]> posted:

Hi ,

I have always thought it made no difference. All of a sudden it matters
to me - my code has written a string delimited by quotes to a SQLite database. I'm trying to test the code and am passing strings to a proc
that checks them against what is in the db.

A silly thought : should it be because in Tcl everything is a string, and in SQLite
not everything is a string ?

Olivier.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

On 10/09/2025 08:49, Alan Grunwald wrote:

On 10/09/2025 04:22, Rich wrote:

Alan Grunwald <[email protected]> wrote:

Hi,

I admit that I'm fairly undisciplined about whether I write

set var "A string with spaces"

or

set var {A string with spaces}

I have always thought it made no difference. All of a sudden it matters
to me - my code has written a string delimited by quotes to a SQLite

Please be less ambigious.  Is the string delimited by quotes (") or do
you actually mean it is delimited by braces ({) but you say "quotes"?

If what you got in the sqlite db was {a string with spaces} then the
most likely cause was you used a variable containing a list in a string
context, in which case you'll get braces added (sometimes) when Tcl
converts the list to a "string representation".

I.e., you've likely mixed together strings and lists and are seeing the
"stringified list" in the sqlite db.

   $ rlwrap tclsh
   % proc test {args} {puts $args}

'args' here inside the proc is actually a list.  The "puts $args" is
using a "list" in a "string context", so Tcl outputs the string
representation of the list.  Which, as you see below, results in added
braces sometimes:

   % test abc
   abc
   % test "abc def"
   {abc def}
   %

Thanks for the reply Rich. As I said on other messages, I can't give you
a proper response, but I'll get back to you properly later in the day.

I'm pretty sure that I've written a string to the database with real double-quotes ("). I should be able to produce a one-liner command-line
to extract it from the database, but had written that db to /tmp and
it's gone away after an overnight reboot, and I can reproduce the
database right now...

I definitely believe that I have written quotes (") to the database;
witness this command-line one-liner:

echo "SELECT cha_mods FROM changes" | sqlite3 /tmp/save3-1.0.db
variant "Testing testing" gender female

(A side issue, completely off-topic - feel free to ignore. All this is
in a tcltest script. I've added -constraints quotingProblem to the tcltest::test command. Is there a non-intrusive way that I can set this constraint to true and make the test run? At the moment I'm echoing 'tcltest::testConstraint true' and 'source <test_script>' and piping the result to tclsh. Is there anything cleaner?)

I want to determine whether my problem is in the 'real' code that writes
a quoted string to the database but shouldn't, or whether it lies in the
test code that is comparing results incorrectly. All the while, sharing
only the minimal amount of code. Any suggestions?

Thanks again
Alan
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

* Alan Grunwald <[email protected]>
| I definitely believe that I have written quotes (") to the database;
| witness this command-line one-liner:

| echo "SELECT cha_mods FROM changes" | sqlite3 /tmp/save3-1.0.db ...

Note that in this example you do *not* write quotes to the database.

The "" is handled by the shell to combine all the words in between as
one argument to 'echo'. The sqlite does not 'see' the "" quotes at all.

In this example, using either of

echo "SELECT cha_mods FROM changes"
echo SELECT cha_mods FROM changes

is completely identical as far as the sqlite command is concerned.

Most probably your real problem was using a TCL list in a string context
(cf the usage of 'args' in your examples upthread), in which case TCL
adds syntactic sugar to make the list reparsable as list.

If you need a string (eg when constructing an SQL command), you need to
convert the list to a string by eg using [join] or in the case of SQL a
safe method to avoid all kinds of security issues if the list text comes
from an unsafe source (user input). I think the tdbc interface has
methods for such tasks (not sure).

proc foo {args} {
puts "args as list: $args"
puts "args as string: [join $args]"
}

foo one two three
=>
args as list: one two three
args as string: one two three

foo "one two three"
=>
args as list: {one two three}
args as string: one two three

foo {one two three}
=>
args as list: {one two three}
args as string: one two three

HTH
R'
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

On 10/09/2025 17:11, Alan Grunwald wrote:

On 10/09/2025 08:49, Alan Grunwald wrote:

On 10/09/2025 04:22, Rich wrote:

Alan Grunwald <[email protected]> wrote:

Hi,

I admit that I'm fairly undisciplined about whether I write

set var "A string with spaces"

or

set var {A string with spaces}

I have always thought it made no difference. All of a sudden it matters >>>> to me - my code has written a string delimited by quotes to a SQLite

Please be less ambigious.  Is the string delimited by quotes (") or do
you actually mean it is delimited by braces ({) but you say "quotes"?

If what you got in the sqlite db was {a string with spaces} then the
most likely cause was you used a variable containing a list in a string
context, in which case you'll get braces added (sometimes) when Tcl
converts the list to a "string representation".

I.e., you've likely mixed together strings and lists and are seeing the
"stringified list" in the sqlite db.

   $ rlwrap tclsh
   % proc test {args} {puts $args}

'args' here inside the proc is actually a list.  The "puts $args" is
using a "list" in a "string context", so Tcl outputs the string
representation of the list.  Which, as you see below, results in added
braces sometimes:

   % test abc
   abc
   % test "abc def"
   {abc def}
   %

<snip>

I definitely believe that I have written quotes (") to the database;
witness this command-line one-liner:

echo "SELECT cha_mods FROM changes" | sqlite3 /tmp/save3-1.0.db
variant "Testing testing" gender female

<snip>

I want to determine whether my problem is in the 'real' code that writes
a quoted string to the database but shouldn't, or whether it lies in the test code that is comparing results incorrectly. All the while, sharing
only the minimal amount of code. Any suggestions?

The test script generates the database via

$db save $d -default {variant "Testing testing" gender female}

if I change this to

$db save $d -default \
[dict create variant "testing testing" gender female]

it works fine. (The string written to the database is delimited by curly brackets.)

The argument to the -default flag was originally conceived as a list of name/value pairs, but I've decided it is better thought of as a
dictionary. (They are equivalent aren't they?)

I think this indicates an error in the 'real' code which I shall attempt
to resolve on my own. I'll report back when I locate and fix the
problem, or if I need further help/guidance.

Many thanks for reading along and the nudges in the right direction.


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

Alan Grunwald <[email protected]> wrote:

$db save $d -default {variant "Testing testing" gender female}

This above *will* pass along a string that has the quotes (") literally present in the string. Curly brackets cause the Tcl parser to take the contents inside as a literal string (almost [1]) and in your example above, the quotes (") will remain in the string.

If you then insert that string, without further filtering, you'll get
literal quotes stored in the db.

[1] see rule [6] in the Tcl man page
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

On 10/09/2025 22:39, Rich wrote:

Alan Grunwald <[email protected]> wrote:

$db save $d -default {variant "Testing testing" gender female}

This above *will* pass along a string that has the quotes (") literally present in the string. Curly brackets cause the Tcl parser to take the contents inside as a literal string (almost [1]) and in your example above, the quotes (") will remain in the string.

If you then insert that string, without further filtering, you'll get
literal quotes stored in the db.

[1] see rule [6] in the Tcl man page

Thanks again Rich. It turned out (no surprise really) that the problem
was wholly in the test script and I'm confident that it won't happen "in service". I modified the software to normalise the dictionary

set normalisedDict [dict create]
dict for {k v} inputDict {
dict set normalisedDict $k $v
}

I had completely overlooked the fact that I was creating the test data
using braces surrounding a quoted string.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

On 11/09/2025 18:08, Alan Grunwald wrote:

    set normalisedDict [dict create]
    dict for {k v} inputDict {
        dict set normalisedDict $k $v
    }

There are several shorter ways to accomplish the same thing:

set normalisedDict [dict map {k v} $inputDict {set v}]
set normalisedDict [dict merge {} $inputDict]
set normalisedDict [dict remove $inputDict]
set normalisedDict [dict replace $inputDict]


Schelte

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

On 11/09/2025 20:28, Schelte wrote:

On 11/09/2025 18:08, Alan Grunwald wrote:

     set normalisedDict [dict create]
     dict for {k v} inputDict {
         dict set normalisedDict $k $v
     }

There are several shorter ways to accomplish the same thing:

    set normalisedDict [dict map {k v} $inputDict {set v}]
    set normalisedDict [dict merge {} $inputDict]
    set normalisedDict [dict remove $inputDict]
    set normalisedDict [dict replace $inputDict]

Schelte

Fascinating.

Thanks Schelte!


Alan
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

* Schelte <[email protected]>
| On 11/09/2025 18:08, Alan Grunwald wrote:
| >     set normalisedDict [dict create]
| >     dict for {k v} inputDict {
| >         dict set normalisedDict $k $v
| >     }

| There are several shorter ways to accomplish the same thing:

| set normalisedDict [dict map {k v} $inputDict {set v}]

I really don't understand what that accomplishes besides a copy of the
dict? Could you give an example where the src and dest dicts differ?

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

From Newsgroup: comp.lang.tcl

Am 12.09.2025 um 15:42 schrieb Ralf Fassel:

* Schelte <[email protected]>
| On 11/09/2025 18:08, Alan Grunwald wrote:
| >     set normalisedDict [dict create]
| >     dict for {k v} inputDict {
| >         dict set normalisedDict $k $v
| >     }

| There are several shorter ways to accomplish the same thing:

| set normalisedDict [dict map {k v} $inputDict {set v}]

I really don't understand what that accomplishes besides a copy of the
dict? Could you give an example where the src and dest dicts differ?

R'

The string representation is vanished, which may have duplicated keys.
As this is later on saved to the data base as a string representation,
this is crucial.

set inputDict {a 1 a 2 b 3}
set normalizedDict [dict merge $inputDict {}]

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

Am 12.09.2025 um 15:53 schrieb Harald Oehlmann:

Am 12.09.2025 um 15:42 schrieb Ralf Fassel:

* Schelte <[email protected]>
| On 11/09/2025 18:08, Alan Grunwald wrote:
| >      set normalisedDict [dict create]
| >      dict for {k v} inputDict {
| >          dict set normalisedDict $k $v
| >      }

| There are several shorter ways to accomplish the same thing:

|     set normalisedDict [dict map {k v} $inputDict {set v}]

I really don't understand what that accomplishes besides a copy of the
dict?  Could you give an example where the src and dest dicts differ?

R'

The string representation is vanished, which may have duplicated keys.
As this is later on saved to the data base as a string representation,
this is crucial.

set inputDict {a 1 a 2 b 3}
set normalizedDict [dict merge $inputDict {}]

sorry, the "dict merge" does not work.
This works:
set inputDict {a 1 a 2 b 3}
set normalisedDict [dict create]
dict for {k v} $inputDict {dict set normalisedDict $k $v}

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

On 12/09/2025 16:16, Harald Oehlmann wrote:

sorry, the "dict merge" does not work.

The dict merge does work the way I wrote it:

set normalizedDict [dict merge {} $inputDict]


Schelte

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

* Harald Oehlmann <[email protected]>
| Am 12.09.2025 um 15:42 schrieb Ralf Fassel:
| > * Schelte <[email protected]>
| > | set normalisedDict [dict map {k v} $inputDict {set v}]
| > I really don't understand what that accomplishes besides a copy of
| > the
| > dict? Could you give an example where the src and dest dicts differ?
| > R'

| The string representation is vanished, which may have duplicated keys.

Ah, I see. Here the inputdict is not really a dict (which cannot have duplicate keys), but some even-element list which is accepted by TCL as
a dict representation.

For that,

set inputdict {a b a c}
dict create {*}$inputdict
=> a c

should also work, no?

TNX
R'
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

Am 12.09.2025 um 17:07 schrieb Schelte:

On 12/09/2025 16:16, Harald Oehlmann wrote:

sorry, the "dict merge" does not work.

The dict merge does work the way I wrote it:

set normalizedDict [dict merge {} $inputDict]

Schelte

Sorry, Schelte, you are always right...
--- Synchronet 3.21a-Linux NewsLink 1.2