open "| ..." / redirection problem
Stephen P. Hill
I am having trouble with tcl exec of a pipeline.
The problem as I see it is that since tcl exec
normally doesn't involve a shell process, it
does it's own handling of ">" and "<".
My usage involves an 'rsh' over to another host,
so there is a KSH process involved on that other
host, and I want that process to redirect stderr
in _part_ of the command.
Looking at the open/exec manpages, it looks like
it will not pass the redirection to the far-end
process, it will interpret them locally. I tried
escaping them with \ but that didn't help.
A rough outline is this:
set cmd rsh
set args "-l $login $ip if kill -0 \$(cat /tmp/.lock) 2>/dev/null ;
then print -u2 LOCKFILE ERROR; fi "
set fp [open "| nohup $cmd $args" ]
Then there is a fileevent handler and a loop that calls vwait
until the process is done.
This code should succeed if there is no lock file, or if
it contains a pid that is currently not active, or even
it it contains non-numeric junk ( hence the need to
redirect stderr ).
If there is a lock file and it contains a pid of a
running process, it should fail - by printing a
message to stderr.
If I replace that with something simple like "touch failfile"
it does create that file at exactly and only the right times,
so I know the rest of the code is functioning - but my
stderr message is being discarded.
I can not switch to ssh. I cannot majorly rewrite
the way the code works either.
I have one other option - emit that 3 lines of KSH to
a local script file, ship it over to the machine,
and then execute it. I would rather just fix this
line, though.
Any ideas?
Thanks,
Stephen Hill
steph...@alcatel-lucent.com
Fredderic
"Stephen P. Hill" <stephe...@speakeasy.net> wrote:
> The problem as I see it is that since tcl exec
> normally doesn't involve a shell process, it
> does it's own handling of ">" and "<".
I think there's some discussion of this in the wiki and even a TIP to
resolve it. Though I haven't looked at it in ages, so I can't remember
what was actually being done. (And I'm not about to go looking,
either, as anyone who's read a few of my posts today will have noticed.
I'm massively behind in all the newsgroups and mailing lists I follow,
so I'm cutting my way through them as quickly as possible.)
The solution to me, seems to be to eradicate the syntactic sugar from
[exec], and get back to TCL's nature. Allow stdin, stdout, and stderr,
to be specified directly through arguments to [exec], rather than syntax
within the command, and have the command name and its arguments
formatted as a list. Something like;
exec -in $fi -cmd {cmd1 arg1} -out $fo -cmd {cmd2 arg2}
Heck, [exec] could even get away with simply allowing its syntax to be
re-ordered like this;
exec <$fi cmd1 arg1 | >$fo cmd2 arg2
If it notices redirection being performed first, then everything up to
the pipe symbol is arguments. However the option format would make it
possible to provide other file descriptors, in/out descriptors, and all
sorts of other wonderful things that are handy when the command being
[exec]d is actually just another part of the same application. Being
able to pass a bi-directional stream, or a [socket] directly as a file
descriptor in addition to the standard i/o descriptors, could be useful
in such cases (though I'm not sure whether that's portable to
non-*n?x's).
Although I still personally like the idea of passing each command in
the pipeline as a discrete list, because then you can even give the pipe
symbol as an argument to a command, without having to worry about
quoting.
Fredderic
Alexandre Ferrieux
> On Fri, 21 Sep 2007 02:09:45 -0500,
> "Stephen P. Hill" <stephenph...@speakeasy.net> wrote:
>
> > The problem as I see it is that since tcl exec
> > normally doesn't involve a shell process, it
> > does it's own handling of ">" and "<".
>
> I think there's some discussion of this in the wiki and even a TIP to
> resolve it.
Yes. It was:
As for the TIP, I never went past the slight itch of the idea (a
stronger itch is required to go bug Donal with a formal request ;-)
Also, I like your idea of reintroducing sh's ability to use file
descriptors above 2 (3> ... 9> etc.), though actually using them with
pipes would need the implementation of standalone pipes like in
(stronger-itch) TIP 304 ( http://www.tcl.tk/cgi-bin/tct/tip/304.html
):
set p1 [pipe]
set p2 [pipe]
set cmd1 [list foo bar with a literal | inside ]
set cmd2 [list gnu gnats > and < are literal too ]
exec -newsyntax $cmd1 3>@ $p1 | $cmd2 5<@ $p2 2>@ stderr
# here you can freely fileevent on the read side of $p1
# or puts to the write side of $p2
The general syntax of [exec -newsyntax] would then be:
exec -newsyntax list [redirs ] [ | list [redirs]]*
And redirs can be
-unary like 3>@ $p1
-nullary like 3>&4 (same semantics as sh's)
-Alex