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.
