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

Reply via email to