At TCL, type " test it's showtime " and you will get error:
[2] Uneven number of delimiters (' " \).

It's perfectly logical, there for a purpose, and we wouldn't want to
get rid of it.

However, these days I'm using TCL as a processor for external requests
where we may not have matched quotes. For example, I'm allowing mobile
phones to send/receive SMS and email to other applications and devices
through D3 using a command like "email abc (AT) def (DOT) tld Subject Text".
That's passed from the remote program or device as a TCL command like:
WEB.SMS email abc (AT) def (DOT) tld Subject Text.

I use TCLREAD or SENTENCE() to get the command line and parse it. But
if the command has a mismatched quote, my program doesn't execute
because the TCL processor considers the command line invalid before it
even gets to the verb.

One solution would be to ensure that all commands are wrapped in
quotes, as in WEB.SMS "it's showtime". But that requires changing the
calling routine, which I can do, but then I'd also need to get my
WEB.SMS or any other processor to strip off the leading/trailing
quotes. That solution further requires ensuring on the client side
that the user query doesn't already include single quotes, double
quotes, or backslashes. I would need to escape/replace those
characters and then unescape the input in my D3 programs. I really
don't like that, but unless I get another suggestion I'll have to go
with this.

Just for this usage I'd rather have D3 disable its check for matching
quotes. That feature is there for AQL query processing, but this is
not AQL. Can we disable that check? Does anyone have another
suggestion?

Does anyone see special elegance in one solution over another?

Thanks!
T

At the risk of answering my own question, just writing out a
definition of the problem seems to have been an inspiring catharsis...

I think the solution here is that the TCL command line is a program
dedicated to the processing of specific kinds of input. Rather than
subverting that purpose I should simply execute another program that
parses input and pass that input to the proper processors. The simple
solution is therefore something like this:

I should not execute a command like this at TCL:
MY.CMD ARG1 'ARG2 "ARG3 \ARG4 (unclosed.paren
I should execute MY.CMD, then use INPUT to get the
application-specific argument string, rather than parsing results from
SENTENCE() or TCLREAD. I can check for SYSTEM(14) to make sure there
is some input, and to avoid a having a process hung waiting when there
is no input.

The above requires a number of changes in different places but I'll
write off the time as an enhancement over an originally faulty
implementation. Once the work is done I don't think I'll need to
revisit it too often. The way it is now I'm going to have the same
problem in any MV DBMS and with different connectivity methods.

Any other thoughts?
Thanks again,
T

Tony Gravagno wrote:

I made the changes, errr, that I recommended, and it's all working
fine.

Embarrassed, but hoping this helps someone one of these days.
T

CLEN = SYSTEM(14)
IF CLEN>0 THEN
ECHO OFF
INPUT CMD,CLEN:
ECHO ON
END ELSE
CMD = SENTENCE()
END

"Tony Gravagno" wrote
good,
except in apps more complicated than sms you may someday get a joker
that
sends you whatever control character your basic SET-BREAK is currently...
Or surprises you with extra {or suddenly missing} carriage return bytes, or
char(0)'s
for 'timing', or tabs / escape strings. Having one basic program run another
with
stacked input is a bit clunky though, for instance if the verb invoked is
unexpectedly
missing, the stacked data is executed as subsequent tcl commands. I get
this a lot
when I try to type COPY myfile
then I hit the control-v then I type the to: information,
which is all well and good until I fat-finger it to CPY myfile
or whatever.

Other, more whacky ways to pass data would be
a) shared storage, be it dedicated items or attributes of one item in a
d3 file,
or native-os file(s) {don't think you could get named pipes
to work here}
b) you're working on the interface between d3 and outside world, but
when you're
passing info between d3 programs, you can use named COMMON.
In
some cases you may want to use elaborate APL-style data
'vectors' that are
a string of values and additional args telling what number of
dimensions and
length along each that your values fill. When processing
largely binary info,
you may leave each value as hex digits. I guess the vector
also needs to tell
the data 'type', on second thought. Maybe some diagnostic info
like what
person and program authored the data, and/or a timestamp...
The machines
today are so fast and space is so cheap, there's less need to
scrimp.
c) you can pass short and already sanitized strings through shell
variables. I especially
enjoy stuffing a variable inside a basic program and later
getting a crufty old
PROC to do HCopy @foo
or whatever. @foo can be used in macros {first line N instead
of PQ}
and dict iconv/oconv attribs too, I think. And they are very
global; even down
inside a chain of EXECUTE's you can change @foo and the parent
prog sees it.

That said, I often just convert single quotes to grave symbols, backslashes
to dquotes,
and dquotes to single quotes, then slap an enclosing pair of
backslashes on all.


You wrote
At TCL, type " test it's showtime "
I'd have put it as
At TCL type Display Test it's showtime
since Display is a system verb, but Test is not known.
I omit the dquotes the user is meant to not type in.

Note that the linux shell (or at least bash) has a similar problem. If
you enter one of the double- or single-quote metacharacters on the
command line, the shell goes into input mode until it receives the 2nd
half of the pair. I think I prefer tcl's explicit error msg.

The windows command prompt (or at least the msg command) seems to
handle these characters ok though.

/Scott Ballinger
Pareto Corporation
Edmonds WA USA
206 713 6006

On Apr 10, 7:18*pm, Tony Gravagno <tony_grava... (AT) nospam (DOT) invalid>
wrote:

Read the input from a file (local or remote) who's name is passed via
TCL?

GlenB

On Apr 10, 6:04*pm, Tony Gravagno <tony_grava... (AT) nospam (DOT) invalid>
wrote:
you could use the 'MX' conversion code to pass the argument as
character hex. Then there's no issues with quoting or control
characters.

edclark wrote:
I solved the problem by invoking just the verb and then passing the
data via INPUT, rather than passing data at the command line. As a
quick interim solution I converted quotes and other characters to
unique text values. I really didn't like doing that, it feels sloppy.

However, the source of the call is a website where I can URL encode
the data, and my app does have modules for URL encode/decode. So in
line with what you suggest Ed, I really should have just URL encoded
the data rather than doing the custom encoding.

Grrr, the project I'm working on is very cool, very big, and I'm
plowing through it as fast as I can. I have an issue tracker that is
growing with new enhancement and fix notes as fast as I close others.
(BTW, that's a very refreshing way to develop.) Some logical
solutions are slipping right by as I implement some tricks of the
trade but forget others when I'm not focused. As an example, we had
that whole discussion about unique IDs and it turned out that I had
pretty much already implemented the solution that we came up with
here, but I didn't realize it until I had clipped that code out to
replace it with the code from the forum thread. It's just a small bit
of code, and the pain was nothing more than a head slap, but the point
is that I should have recognized that I was already employing a
technique that we were discussing here - and at other times I'm simply
missing good points that you guys are providing here. As I go through
this project I realize that I employ a lot of techniques that might be
of help to others, I just don't take the time to document them. Well,
that's what blogs are for. I'll post something soon.

Thanks for your comments, guys.
T