Re: Literal pipes in [open "|cmd..."]

On 14 Dec 2006 14:11:47 GMT,
Andreas Leitgeb <avl@xxxxxxxxxxxxxxxxxxxxxxxx> wrote:

In addition, it would probably also be entirely simpler than the
current exec implementation. If it's not an [exec] directive, then
it's a command. No extra parsing neccesary. You can probably do
away with the intermediary pipe directives entirely also (or more
to the point, they'd become optional). ... [+ return fd's]
I'm not principially against this new syntax, I just think
it doesn't fit into exec. Not even with explicit options.

What can be a more TCLish improvement to the existing [exec], then
options to set up the programs descriptors, and each program with its
arguments specified in individual lists. Certainly more TCLish than
the current shell-lookalike syntax, plus it gets rid of any [eval] type
behaviour with respect to the program and its arguments since they're
encapsulated within a list. The only remaining issue is the case of a
program that looks like an [exec] redirection/piping directive and has
no arguments.

Of course, the simplest is to simply support escaping the redirection
directives as I'd suggested, but with a slightly more thought-out
escape character. Though as pointed out, that's not going to be a whole
lot better, either, because whatever character you pick as the
escape, also has to somehow deal with the case of it NOT being an escape
character (double it up?). And now we're getting into some very
NON-TCL realms, indeed.

The command-in-a-list idea IS the best and simplest way to go I've seen
so far in this thread.


Otoh, I could imagine a new command with a clean syntax,
and exec being the compatibility-wrapper-function.

As for a new command with a clean syntax, the only way you're going to
get an exec with clean syntax, is by moving the bells and whistles of
[exec] into options before the program and its arguments, or even
removing most of them from the new [exec] command entirely.

1) Redirection by discrete options (or maybe a dict); would allow you
to attach the programs stdin to an already-opened channel, or join the
programs stderr to stdout. Dump the capability to return the programs
output, or feed it the contents of a variable as input, and always (or
at least an option to) run programs as background tasks.

2) A means to create a pipe that's linked to a variable or procedure.
(Possibly an extension to the [open] syntax, with a leading "<" or ">"
similar to the "|"). Something along the vague lines of this;

proc popen {mode arg} {
foreach {in ou} [create-a-pipe] {break}
switch -exact -- $mode {
"<" {
fileevent $ou write $arg
return $in
}
">" - out {
fileevent $in read $arg
return $ou
}
"<<" {
fconfigure $ou -blocking 0
puts $ou $arg
return $in
}
">>" {
fileevent $in write built-in-variable-appender $arg
return $ou
}
}
}

(I could well have my ins and outs and what-not confused, but you get
the idea)

3) Possibly restore some user-friendliness by allowing [exec]-like
redirection directives within the descriptor binding arguments
(though they'll still be a little simpler and neater).

4) Possibly providing a means to request that a descriptor be filled in
by a pipe automatically. You'd then need to make the return value a
list containing the pid of the process, and a list of the channels it
was provided. You could then use [lindex] to pluck out the one(s)
needed for chaining onto the next command.

5) A command (and/or an option) to wait for a child process to
complete. Having it as a discrete command would be more useful, but as
an option would be easier.

Have I missed anything? Though when it's all said and done, I'm not
entirely certain how much cleaner it'll end up being. Though there is
some rather handy functionality in there... Point #2 certainly has uses
outside of [exec].


Fredderic
.

Relevant Pages

  • Re: wScript.Shell Problems
    ... the completion of the underlying process. ... However, the Exec procedure is ... Here is why i went to the RUN command, it is my understanding that the ... EXEC command does not allow for the BOOLEAN indicating wether the ...
    (microsoft.public.scripting.vbscript)
  • Re: Problem in calling c programs and compiling them in tcl/tk
    ... Are you using Tcl's glob command to do this? ... using exec gcc filename.c and later exec ./a.out filename.c. ... the execution of a command that might generate a Tcl error. ... i can call a c program and compile it? ...
    (comp.lang.tcl)
  • Re: xp_cmdshell default path (system32) problem
    ... exec xp_cmdshell @cmd1 ... - specify the full path in the del command ... ensure that xp_cmdshell ALWAYS executes under the security context of ... I haven't executed the actual erase statements yet but rather have been ...
    (microsoft.public.sqlserver.programming)
  • Re: passing colon or comma as part of arg list to exec
    ... and so are turned into whitespace separating the arg for the ... Using the LIST form of exec there is no ... shell involvement thus: and, should not be treated as shell ... Any if you issue the command from the command line by hand, ...
    (comp.lang.perl.misc)
  • Re: Expect scripting
    ... I reverted to what I am familiar with which is script and used exec ... COMPL is the exact prompt from the remote processor? ... If the command were to be entered to the telnet session to this ... I strongly recommend you read.- Hide quoted text - ...
    (comp.lang.tcl)