On Sat, Oct 15, 2016 at 8:12 PM, Stephen R. van den Berg <s...@cuci.nl> wrote:
> Chris Angelico wrote:
>>Two features added to the Process module. Firstly, a simple wrapper
>>Process.check_run that calls Process.run and throws an error if the
>>exit code isn't 0;
> This is a bit overkill, I'd say.  It's not generic enough to put in the
> lib.  What if you want to check for a certain range of exitcodes instead?
> If you want this, I'd say you inherit the class and add your own convenience
> functions to it, but at application level.

There's a strong convention that zero == success, nonzero == failure,
so this would apply as-is to a lot of programs. Obviously this
shouldn't be the one and only way to run a subprocess (this is NOT a
proposed change to Process.run, it's a separate function), so if you
want to invoke grep(1) and accept 0 (lines found) and 1 (no lines
found) but not 2 (error), then you'd make an app-specific function;
but 0 vs other is common enough that I think this fits the standard

Example of prior art: Python's subprocess.check_call and check_output
functions raise an exception on non-zero return value:


>> and secondly, a means for Process.run() to leave
>>stderr attached to the console. The intention is for this to be used
> That seems useful, so I'd welcome that.
> But then support it for stdout too.
> Then again, maybe this is better off generalised, into requiring/allowing
> you to specify things like:
> ({"stdout":Stdio.stdout, "stderr":Stdio.stderr})
> instead of the magic "-".
> This would support adding different objects too, in order to redirect
> directly into a file or some other pipe.

If you don't want to redirect either, or if you want to redirect them
both to files, use Process.Process or Process.create_process directly.
The advantage of Process.run is that it captures the output. I suppose
you might conceivably want to capture stderr but leave stdout attached
to the console, but it's a lot less common than "run program, give it
input, retrieve output, but if it displays an error, let that be
seen". I can't think of any use-cases for the converse. Process.run()
is great, but there are a lot of times when I have to either replicate
half of its code, or use run() and risk squashing an unexpected error.
With check_run, I'd be able to have virtually the same API, but with
the declaration that a program error is an exception.

Consider a simple way to get audio file information:

string info = Process.run(({"soxi", "audio_01.wav"}))->stdout;
//proceed to parse the given info, eg:
sscanf(info, "%*[\n]%{%s: %s\n%}", array lines);
mapping fields = (mapping)lines;

If soxi is not available, this will raise an immediate exception,
rather than charging on blindly; but if audio_01.wav isn't found,
there's no indication of the actual problem - you just don't get any
useful output. Using check_run causes an instant failure, saying that
the process exited 1; and keeping stderr attached to the console would
let the user see the message from soxi:

string info = Process.check_run(({"soxi", "audio_01.wav"}),
(["stderr": "-"]))->stdout;

In fact, this usage could itself be wrapped up another level, if
desired. I've tossed another commit onto the branch to add a
check_output function, but this one is less significant (it's just a
one-liner). With check_output, omitting the modifiers mapping gives
the natural and obvious behaviour of the above line of code.


Reply via email to