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

[Jesse Phillips]

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).

> 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).

> Path.toString() automatically quotes paths correctly when they 
> contain spaces. So you can just pass it off to spawnShell or 
> whatever and it's automatically all ready-to-go. Don't even 
> need to call the std.path.escape*() funcs (which I've had 
> trouble with on windows anyway, although DMD #10863 is 
> apparently fixed in master now, so that should at least help).
>
> Of course, if for any reason you need to keep the path 
> un-quoted, there's Path.toRawString() for that.

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:

     auto cmd = ["dmd"];
     cmd ~= "file.d";//...

Is just a nice way to build a command.

> 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.

> >> - Less-pedantic filesystem operations for when you don't
> care whether
> >> it exists or not: existsAsFile, existsAsDir, existsAsSymlink,
> >> tryRename, trySymlink, tryCopy, tryMkdir, tryMkdirRecurse,
> tryRmdir,
> >> tryRmdirRecurse, tryRemove: All check whether the source
> path exists
> >> and return WITHOUT throwing if there's nothing to do.
> >
> > This is my biggest gripe with the current available functions!
>
> Yea, I'm constantly making wrappers for those things in my 
> scripts. Finally decided to just toss them into a common lib.
>
> I *do* think std.file's pedantic behavior with those does make 
> a lot of sense in the general case. I'm not sure that I'd even 
> want std.file to relax those checks by default. But for simple 
> shell-script-like stuff, it does tend to be more bother than 
> benefit.

Yeah, going back to being strict is harder.

> >> - One simple call, runShell, to run a shell command
> script-style (ie,
> >> synchronously with forwarded stdout/in/err) from any working
> >> directory. (Also automatically works around DMD #10863
> without waiting
> >> for v2.066 - BTW, thanks all involved who fixed that.)
> >
> > Aside from the bug, I don't understand what this provides
> over "execute."
>
> First of all, "spawn(Process|Shell)().wait()" is a better 
> comparison for runShell than execute(Process|Shell). The 
> execute functions, at least by default, hide the child's 
> stdout/stderr. Granted, execute does capture the child's 
> stdout, so you *could* output it yourself afterwords, but then 
> the user doesn't see the output in real-time (and forget about 
> anything interactive), so that's not a good solution.

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.

> - 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.

> Plus there's the automatic command echoing (not that I couldn't 
> do that in some more direct std.process wrappers, like I do for 
> certain std.file functions).

I wonder if a generic wrapper could be created to handle this.