Scriptlike: New lib to aid in writing script-like programs

[Nick Sabalausky]

On 2/11/2014 8:01 PM, Jesse Phillips wrote:
> On Wednesday, 12 February 2014 at 00:07:42 UTC, Nick Sabalausky wrote:
>> As for the license, if you don't mind switching to zlib then great,
>> just go ahead and submit a pull request if you'd like to. But I'm not
>> married to zlib license or anything. My reasons for using zlib license
>> are relatively minor, and I'm not opposed to switching to Boost,
>> especially since it's already the Phobos license after all. What are
>> your thoughts?
>
> I've been using Boost to be compatible Phobos. I haven't released
> anything which I feel needs a more restrictive license (zlib I think is
> permissive).
>

zlib's about as permissive (and easy to read) as it gets without going 
all the way to the "Do WTF You Want" license (which I actually use for 
REALLY trivial things)

It's basically like a re-worded MIT license:
http://opensource.org/licenses/Zlib


>> So with Scriptlike, I'm hoping to avoid the need to ever deal with
>> slashes at all, because all the clutter and meticulous care of always
>> doing it the proper std.path-way is (hopefully) hidden
>> behind-the-scenes via the Path type.
>
> Any hard coded paths I'll use / and buildPath for everything else. My
> experience so far has been positive on Windows (but maybe I still have
> some legacy conversions from the old days).

Yea, I like to use hardcoded / too, it's visually pleasant, 
minimally-verbose and Windows usually does accept it just fine. Problem 
is I can't always *rely* on paths always having / without being careful 
to sanitize my inputs.


> Ah, I use execute(char[][]) and pipeProcess(char[][]) these bypass the
> shell (it seems) and require that the arguments aren't quoted. I prefer
> these because:

Oh, that's right, it's "execute", not "executeProcess". I overlooked 
that naming detail. And it's possible I misunderstood pipeProcess when I 
looked at it before, I'll have to look again.

The "*Shell" ones are nice because I know I can do anything I can do on 
the cmdline, like piping and redirecting and such, in just the same way 
as I would the command line. Luckily it works pretty much the same on 
both Windows and Bash. Although come to think of it, BSD's default shell 
(which I actually quite like in certain ways - specifically, searching 
through the command history) handles redirecting differently.


>      auto cmd = ["dmd"];
>      cmd ~= "file.d";//...
>
> Is just a nice way to build a command.
>

Hmm, yea, that's a good point.

In any case, I didn't necessarily intend to leave Scriptlike's process 
features limited to just the current "runShell", so this is all good 
stuff to think about.


>> Do you think enabling dry run should automatically enable command
>> echoing?
>
> Yes, I can't think of a reason I wouldn't want it to.
>

The only downside I can think of is if there *were* some reason to do 
dry-run without echoing, there'd be no way to do it. Then again, I 
already intended to allow a custom OutputRange sink for the echoing, so 
if someone really wanted to squelch the echoing, they could just pass in 
a do-nothing OutputRange. Ok, I'll do it that way then.


> Hmm, I've been needing to retain the output and do things with it quite
> a bit. Haven't played with it, but you may be able to get interaction by
> using pipeProcess, but then there is just more work to make it act like
> spawn.
>

Yea, that parsing the output can definitely be useful in certain cases. 
I haven't really done it much yet because the old std.process couldn't 
really handle it well, and since then, I either haven't needed to or 
maybe I've just gotten used to avoiding it.

Actually, I've been really wanting to make a D equivalent of...I forget 
the name offhand, but it's fairly well-established tcl lib specifically 
designed for automating interactive text-based sessions. "expect", I 
think? I may do that soon, it'd fit well in Scriptlike.


>> - runShell optionally takes a Path to use as the initial working
>> directory to launch the process from (and then uses scope(exit) to
>> automatically chdir back when the process finishes). Nothing in
>> std.process does that right now, although there is a request in
>> bugzilla for it: http://d.puremagic.com/issues/show_bug.cgi?id=11363
>
> That is likely quite useful.

Yea, I've needed to do that SOOO many times. I've gotten really tired of 
cluttering my scripts with:

{
     auto saveDir = getcwd();
     chdir(somePath);
     scope(exit) chdir(saveDir);
     ...
}

Thank goodness it's D though, otherwise that'd be much worse. Scope 
guards are one of my favorite features of D. Brilliant solution.