Home > Archive > Tcl > January 2006 > redirection in exec with leading <
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
redirection in exec with leading <
|
|
| billposer@alum.mit.edu 2006-01-24, 7:05 pm |
| Exec treats a leading '<' as redirecting stdin even if it does not
stand alone, so that
exec foo < bar
and
exec foo <bar
are treated identically. I suppose that this was supposed to mimic the
behaviour of the Unix shells. However, in the shells it is possible to
get around this by escaping the '<', e.g.
foo \<bar
will execute foo with the argument "<bar" rather than redirecting stdin
to "bar". As far as I can tell, there is no way to avoid redirection in
Tcl - none of the quoting techniques that I have tried work. Am I
wrong? Is there a way to pass an argument with a leading '<'? If not, I
wonder if a change would not be desirable.
| |
| Don Porter 2006-01-24, 7:05 pm |
| billposer@alum.mit.edu wrote:
> ... As far as I can tell, there is no way to avoid redirection in
> Tcl - none of the quoting techniques that I have tried work. Am I
> wrong?
You are not wrong.
> Is there a way to pass an argument with a leading '<'?
No.
> If not, I wonder if a change would not be desirable.
See TIP 240. If you like it, beat the drum for it on the
tcl-core@lists.sf.net mailing list. If you think it needs work,
contact the author with your improvement suggestions.
--
| Don Porter Mathematical and Computational Sciences Division |
| donald.porter@nist.gov Information Technology Laboratory |
| http://math.nist.gov/~DPorter/ NIST |
|_______________________________________
_______________________________|
| |
| billposer@alum.mit.edu 2006-01-24, 9:58 pm |
| Thanks.
I will certainly advocate for TIP 240, or at least changing the
behavior with respect to "<". There are a fair number of situations in
which it is desirable to pass arguments containing "<" to other
programs so if one is using Tcl for this purpose it is a pain.
| |
| Andreas Leitgeb 2006-01-25, 7:57 am |
| billposer@alum.mit.edu <billposer@alum.mit.edu> wrote:
> I will certainly advocate for TIP 240, or at least changing the
> behavior with respect to "<". There are a fair number of situations in
> which it is desirable to pass arguments containing "<" to other
> programs so if one is using Tcl for this purpose it is a pain.
Specifically for escaping special chars for exec, there exists
another "trick", but that involves an extra program (e.g. written
in C, perl, but unfortunately not a tcl-script)
The external program would scan it's command line arguments,
and for each one of these that start with a single-quote
('), it would strip *at most one* such character. For
this description lets name the command "tclexechelper"
Note, that the '-char is *not* special to tcl.
Then, in tcl, you would write
exec tclexechelper yourprogram xyz '$somearg '<stdin >stdout
and the quotes would prevent tcl's exec from seeing e.g. the
"<stdin", thus pass it on to the helper, which would then
strip the leading quote from each argument then call yourprogram
with the exact args "xyz", "value_of_somearg" and "<stdin",
but not ">stdout" because this one is not quoted and thus seen
and handled by tcl's exec (xyz is also unquoted, but not magic
to exec).
Now, suppose $somearg does happen to begin with a
single quote: no problem, tclexechelper then sees two
quotes and strips only one and lets the second one go
through to yourprogram.
The advantage is: you can use it with any current or
even aged tclsh and need not wait(nor hope) for TIP 240.
The di vantage is: you need that extra binary.
PS: At some point I proposed some changes to tcl's exec,
that would remove the need for tclexechelper, but that
change didn't really fit well, and had some clumsiness
involved. If you don't mind producing (and shipping)
your own version of tclsh, I could send you the patch,
though I don't know whether it will still apply cleanly.
| |
| Donal K. Fellows 2006-01-25, 7:57 am |
| Andreas Leitgeb wrote:
> Specifically for escaping special chars for exec, there exists
> another "trick", but that involves an extra program (e.g. written
> in C, perl, but unfortunately not a tcl-script)
I often use a bourne shell script for that when I'm on Unix. Indeed,
I've found that in those situations where I want to expose to users a
simple scripting interface, it's better (i.e. they prefer it) to expose
bourne shell and just hand things off using an invokation like this:
exec /bin/sh -c $theScriptQuotedAnyOldWay <realStdin >realStdout
Exposing Tcl is nice for some (most!) things, but when they expect shell
quirks it is better to give them real shell quirks...
Donal.
| |
| Cameron Laird 2006-01-25, 7:15 pm |
| In article <slrndtemac.56k.avl@gamma.logic.tuwien.ac.at>,
Andreas Leitgeb <avl@logic.at> wrote:
>billposer@alum.mit.edu <billposer@alum.mit.edu> wrote:
>
>Specifically for escaping special chars for exec, there exists
>another "trick", but that involves an extra program (e.g. written
>in C, perl, but unfortunately not a tcl-script)
| |
| billposer@alum.mit.edu 2006-01-26, 9:57 pm |
| Thanks. I fixed configure following DKF's instructions and got Tcl to
compile, the result of which was the discovery that my idea of what
needed to be changed was incorrect. Not surprising since I have little
experience of the Tcl source.
Bill
|
|
|
|
|