-Original Message-
From: Larry Wall [mailto:[EMAIL PROTECTED]
On Tue, Apr 20, 2004 at 03:53:31PM -0400, Aaron Sherman wrote:
: In specific, here is a proposal for execution:
:
: multi run(string $command) returns(Process) {...} # Funky shell default
: multi run(Process $process) returns(Process) {...} # Relies on
$process.cmdline
Eh? What does it mean to run a process that presumably is
already running?
use strings :LC_CTYPE('x-en-US-gnu');
my $shell = new Process('/bin/bash');
my $ide = $shell-run('/usr/bin/emacs');
$ide-run('\M-xperl6-interactive\n');
$ide-run(-'END_PERL');
use Hash::halfdan;
%hash`access`tricks++;
END_PERL
$ide-run('\M-xkill-interactive\n');
$ide-run('\C-x\C-z');
$ide-wait(3);
$ide-kill('USR1')
unless $ide-done;
$shell-kill('HUP');
: multi run(Program $program, IO::Mode $mode=undef)
returns(Process) {...}
:
: which gives us our process control, all nicely bottled up:
:
: my Process $p = run(find / -name null);
: say Spawned find $($p.getpid);
: $p.kill('TERM');
:
: But if you don't want that, you can always:
:
: run(find / -name null).wait;
:
: which might have an alias called system.
I'm trying to avoid system actually, since it's backwards on its
booleanness in Perl 5, and it would be confusing to just swap it.
Let's use unary backtick as a cheap qx for atomic commands.
It's twice as ergonomic as the current implementation. :-) :-) :-)
: And if you provide mode:
:
: my Process $p = run(program=find / -name null, mode=r);
:
: Then you actually get back a:
:
: class ExecPipe is Process does IO::Handle {...}
:
: which lets you do:
:
: say Found null at: $p.getline;
:
: and which could have a wrapper:
:
: $x = readpipe(pwd);
:
: ahhh... simple.
Er, yeah...
: open2, open3, exec and all manner of other strange things should be
: simple aliases for complex run invocations.
The complicated interface should have a longer name name run. I was
thinking run was the new name of system, and possibly is
context sensitive on its I/O redirection.
'execute'?
: The reason for making Program an object? Why for this:
:
: run(Program(path=find,name=finding null,args=[/
-name null],exec=true));
:
: which has the alias exec.
I confess I don't understand what value making Program an object has in this
context. If you're going to exec, in the unix sense, then creating a Program
with exec=true cannot do anything except get ready for the run/exec call.
To my feeble mind, there's not much benefit there, unless you figure that
exec+run will catch some class of resource exhaustion error sooner?
I kinda cringe to see exec=true when we just defined :exec to
mean that...
When 'exec' is buried at the end of a hideously complex arglist, as in this
example, I'll take all the verbosity I can get. It helps my parser resync.
run(Program :pathfind :namefinding null :args[/ -name null] :exec)
That does read better with a little sorting, and of course a method:
Program
:namefinding null :exec
:pathfind :args[/ -name null]
== run;
Which brings up pipelining operators:
class Program {...}
multi *infix:(Program $p, String^IO::Handle $input) { $p.input =
$input; };
multi *infix:(Program $p, String^IO::Handle $output) { $p.output =
$output; };
multi *infix:|(Program $p, Program $q) { $p.output = '|$q'; }
multi *postfix:!(Program $p) is tighter(infix:and) { $p.run;}
Program
:namefinding null
:pathfind :args/ -name null -ls
| Program
:namesorting by size
:pathsort :args-k6d
File
:namenulls.txt
:modeoverwrite
!;
Self-documenting shell scripts? The id recoils in disgust.
: Making this as magical as Perl 5 system would be difficult, though, and
: I'm not sure you need to preserve that particular way of doing things.
Not sure which magic you're referring to. system() is pretty stupid,
other than a little optimization to bypass the shell when it can.
We've got operator overloading and macros. We can make C++ look like COBOL
by comparison.
Whether we want to do so is another question.
: I leave the definition of Program up to the imagination of the reader.
Oh, oh...
: Incidentally, if Process is a standard class, and happens to do:
:
: class Process {
: ...
: method prefix:~() { return ~($.getpid) }
: method prefix:+() { return $.getpid }
: ...
: }
:
: Then $$ is just a Process object, but behaves exactly as you always
: expected it to.
Beware of expecting too much *n*x in there. prefix:~() should return the
GUID.
;-)
:
: $$.kill(ABRT)
:
: then does what you might expect, as does:
:
: say $$.cmdline;
Okay, but there is no $$ anymore. It'd be $*PID or $*PROC or some such.
'is' this, 'does' that. What ever happened to line-noise?
=Austin
