Re: run / qx/ etc.
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?
: 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.
: 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.
: 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 kinda cringe to see exec=true when we just defined :exec to mean that...
: 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.
: 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.
:
: $$.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.
Larry
RE: run / qx/ etc.
-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
run / qx/ etc.
On Tue, 2004-04-20 at 13:55, Larry Wall wrote:
Okay, let's put this one to rest.
Good, and I'll not try to speak ill of the dead thread, so ignoring hash
and/or array access, let me respond to the end of your message.
As for Cqx//, it probably needs to be completely rethought anyway,
along with Csystem. Perhaps both will be subsumed under a Crun
function of some sort. But that's for a future Apocalypse.
Now, you had to go and do it didn'cha? ;-)
I've been thinking about this for a long time, but for other reasons.
It seems to me that there are dozens of ways to run a program from
within Perl 5. Some are simple, some ugly as sin (sorry, I mean
complex), but given A12, I think we can start to home in on a great
deal of the standard tools.
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
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.
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.
open2, open3, exec and all manner of other strange things should be
simple aliases for complex run invocations.
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.
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.
I leave the definition of Program up to the imagination of the reader.
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.
$$.kill(ABRT)
then does what you might expect, as does:
say $$.cmdline;
--
Aaron Sherman [EMAIL PROTECTED]
Senior Systems Engineer and Toolsmith
It's the sound of a satellite saying, 'get me down!' -Shriekback
