Robert
IMO, braced strings and (optional) judicious use of [subst] is a fair
approximation.
What Problem Are You Trying To Solve?(tm) Unless you're absolutely
wedded to the Heredoc Method, there's almost certainly a better way.
- Adrian
print <<MSG;
You can type anything within the heredoc.
Including "double quotes", 'single quotes', and $variables.
You terminate the heredoc with the herdoc marker you used at the
beginning on a it's own line with no whitespace.
MSG
#!/usr/bin/env tclsh
puts {
You can type anything within the heredoc.
Including "double quotes", 'single quotes', and $variables.
You terminate the heredoc with the matching close brace.
}
Except Perl (and, I think, every other scripting language that implements
heredocs) performs variable substitution in the heredoc itself, and I
know bash also does command substitution. Tcl does neither in braced
strings, hence my mention of [subst].
- Adrian
Robert
I used it in the context of SMTP. I ran a few `system` commands
attached to variables and in my heredoc I created a nice report with
those variables.
Robert
Multi-line text can also be quoted, with "all" the
usual substituions, which can be nice
You can create a correctly escaped string with an auxillary
script (on unix):
#!/usr/bin/tclsh
puts "{[list [read stdin]]}"
and then send the string to it on stdin.
You can then include the stdout of that into your tclsh script.
(A simple way is also to {...} quote the string and replace
every '{', '}', and '\' in the string with '\{', '\}', and
'\\'.
--
SM Ryan http://www.rawbw.com/~wyrmwif/
The whole world's against us.
set today [clock format [clock seconds] -format %D]
set message "
This is a multi-line message.
Produced $today.
Perhaps something like the heredoc described
"
--
| Don Porter Mathematical and Computational Sciences Division |
| donald...@nist.gov Information Technology Laboratory |
| http://math.nist.gov/~DPorter/ NIST |
|______________________________________________________________________|
Robert
Tcl's string handling does that sort of thing naturally. Just use "" or
{} (depending on the type of heredoc you want) and put newlines inside.
Only real difference is that you can't choose your delimiter to be
something completely arbitrary, but that does not seem to be too much a
problem in practice I find.
If it makes you happier, it's conventional to use that sort of thing all
over Tcl, such as in this example with nested heredocs...
proc foo args {
foreach bar $args {
if {$bar eq "spong"} {
puts "I have found a spong; what shall I do?"
} else {
set len [string length $bar]
puts "There are $len characters in this argument:
>>$bar<<"
}
}
}
OK, you can see the trivial one in the [puts] (a rare but occasionally
vital use) but the else clause itself is one, as is the [foreach] body
and the [proc] body. When you get down to it, you'll have been using
heredocs for ages now without noticing. :-)
Donal.
> Robert Hicks wrote:
> > I was wondering if Tcl had something like Perl's "heredoc".
>
> Tcl's string handling does that sort of thing naturally. Just use "" or
> {} (depending on the type of heredoc you want) and put newlines inside.
> Only real difference is that you can't choose your delimiter to be
> something completely arbitrary, but that does not seem to be too much a
> problem in practice I find.
But I think it is the essential characteristic of heredoc. It is
a feature Tcl simply lacks. Not that it is an essential feature,
but it doesn't make sense to call it the same thing as quoting.
--
Donald Arseneau as...@triumf.ca
You're entitled to think whatever you want. Just as I'm entitled to
think you're completely wrong there. :-)
Donal.
exec prog <<"
My
My
multiline
text"
or (more usual):
exec prog <<$var
In these cases, no need to use pipes and fileevents ...
Regards,
Arjen
> Robert Hicks wrote:
> > I just used it today so I am not wedded to it at all. I did think it
> > was nice that I could create a multiline message with interpolation
> > of variables that I could pass to a variable and use elsewhere.
> set today [clock format [clock seconds] -format %D]
> set message "
> This is a multi-line message.
> Produced $today.
> Perhaps something like the heredoc described
> "
I never use heredocs within a function, because they're just so damn
ugly (sometimes they come in handy at the end of a one-shot script,
though). But following this thread, it occurs to me that there is one
big difference between "heredoc"s and a multi-line string in TCL. The
string seems to end up with extra newlines at the start and end.
Certainly an extra one on the first line.
What MIGHT make heredocs bearable in TCL, IMHO, would be a [heredoc]
command that removes any common leader from the lines (allowing for
optional partial indenting on otherwise blank lines, but including
the last line), and then if both the first and last lines are blank,
strip them off too.
They're still damn ugly, though. ;)
Fredderic
I noticed the extra lines using a multi-line Tcl string, so yeah that
would be a good reason to have a "heredoc" type facility. However, I am
probably the only one wondering about this. : )
Robert
instead of
(
echo "do first command"
echo "doc second command"
echo "do $THEDING $MYFILE"
) | my_app_awaitng_input \
| ..
my_app_awaiting_input << EOF
do first command
do second comand
do $THEDING $MYFILE
EOF
and usually for me it's gnuplot that gets input like this.
but you don't have that in tcl on a regular basis.
uwe
Regards,
Arjen
me> but you don't have that in tcl on a regular basis.
as in
"don*t have the requirement/wish"
and not
"don't have the feature"
uwe
Uwe, do you understand clearly what Arjen has been saying? Yes,
a VERY common use of heredocs is to redirect programmatic data
into a process; you're absolutely right about that. The Tcl
perspective, though, is to remember that one of the delights of
Tcl's [exec] is that it offers a better syntax for that same
goal! At that level, it's why Tcl doesn't have a heredoc.
> Uwe, do you understand clearly what Arjen has been saying? Yes,
> a VERY common use of heredocs is to redirect programmatic data
> into a process; you're absolutely right about that. The Tcl
> perspective, though, is to remember that one of the delights of
> Tcl's [exec] is that it offers a better syntax for that same
> goal! At that level, it's why Tcl doesn't have a heredoc.
YES and yes, but..
I was till today not aware that exec had a <<$input option
( I just did not miss it )
on one part due to the fact that i still tend to string my tools
together with a shell script ( usually bash ) thus i tend to use
exec sparingly or inside tcl use [open |myproc w] or go with expect.
This might actually be a bit of "with a hammer in your hand
all problems tend to look a lot like nails".
The nice thing with c.l.t is seeing details of the "hammers" others
cary about ;-)
uwe
Actually, that way you didn't (yet) stumble over a bug
(which is already recorded on sourceforge) with respect
to "<<" and binary data (expecially \0 chars).
uwe
FWIW, it's in the Ousterhout book, which dates it back to 7.3 or earlier.
Donal.