On 2/11/2014 1:52 PM, Jesse Phillips wrote:
> On Tuesday, 11 February 2014 at 11:38:06 UTC, Nick Sabalausky wrote:
>> I've released a little one-module utility, Scriptlike, to help
>> simplify writing shell script-like programs in D:
>>
>>   https://github.com/Abscissa/scriptlike
>
> It looks like you've covered a lot of the short comings for doing some
> cmdln scripting. It also sounds like it would fit right into what I was
> doing (I hand only covered the user input portion)
> https://github.com/JesseKPhillips/JPDLibs/tree/cmdln (I really probably
> should move it into its own project, maybe I should instead submit mine
> to yours? Though I use Boost License).
>

Oh yea, I hadn't even thought of user input :P. I guess I got in the habit of avoiding it in CLI apps. I remember seeing your lib for that a while back and rather liked it.

I think that would fit very well into Scriptlike, as long as you don't mind it all being in the same module as the rest of scriptlike, and preferably using same formatting style (not that that's strictly important, but consistency is nice of course).

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?

> [OT] I also want to thank those behind std.process, std.path, and
> std.algorithms these things have been really awesome and I use heavily
> (great improvements).

///ditto

>> - A thin wrapper over std.path and std.file that provides a dedicated
>> Path type specifically designed for managing file paths in a simple,
>> reliable, cross-platform way. No more dealing with slashes,
>> paths-with-spaces, calling buildPath, normalizing, or getting paths
>> mixed up with ordinary strings.
>
> Personally I've found the new std.path makes this much easier,

Yea, it *definitely* does. But at the same time, I've found I still end up mucking with slashes and such anyway for a couple reasons:

1. In simpler situations, calling buildPath sometimes just seems to make what should be trivial become more verbose than I'd like. So I don't always like to use it even when I know I should.

But with Scriptlike's Path type, it's just a simple partA~partB and slashes are handled behind-the-scenes (internally via buildNormalizedPath). Can't get much less verbose than that :) Maybe not the most efficient strategy, but this is intended for shell-like scripts, so it's unlikely to be anything near a problematic bottleneck.

2. std.path (and buildPath in particular) likes to use / on Posix and \ on Windows. While this makes a lot of sense in certain ways, I find that when I do deal with paths, having all my code internally operate on forward-slashes-only often leads to much, much simpler code. The downside is that not only do I have to sanitize all my inputs to forward-slash-only, I also have to do the same for many paths I get back from std.path. And then I have to convert back to backslashes on windows if I want to display it to the user in a nice OS-correct way, or pass it to certain WinAPI functions.

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.


> I'm not
> user how you can address paths-with-spaces as this depends on who you
> call, internally I don't need to worry. But maybe this simplifies it
> more and is still worth it.

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.


> Command echoing, and dry run are both valuable.

Oh, dry run, of course, I didn't think of that! Some scripts may still have to take extra care to handle dry runs correctly, for example if one step relies on the result of an earlier step *actually* being executed. But Scriptlike could probably help with at least some of the work. I've added a ticket for that: https://github.com/Abscissa/scriptlike/issues/8

Do you think enabling dry run should automatically enable command echoing?

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


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

Regarding runShell vs "spawn(Process|Shell)().wait()", I admit the motivations are somewhat on the weak side, but I think it's still enough to be worth having:

- There's the (now fixed in master for 2.066) bug, like we said.

- Out of all the ways to launch a process with std.process, "spawnShell().wait()" is the *one* way that actually matches a shell script's behavior (aside from the bug), and is therefore (at least IMO and in my experience) the one you'd usually want in a script-like program. But looking at the available choices and options in std.process, it's not immediately obvious how to do "Run a command just like a shell script would". So Scriptlike says "runShell, that's how you do it".

- 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

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

>> - One simple function, fail(string msg), to help you exit with an
>> error message in an exception-safe way. (Does require some minor
>> boilerplate added to your main().)
>
> I've just been using exceptions,

Yea, that's exactly what fail() is, really. It just throws a "class Fail : Exception", and then the user's main() is expected to catch it, do a "stderr.writeln(e.msg)" and return 1.

I wanted to provide a nice way to reduce all that main() boilerplate the user needs, but I'm not sure if that's possible right now. Here's the relevant D.learn thread (ooh, which appears to have some new posts now...):

http://forum.dlang.org/thread/ldc6qt$22tv$1...@digitalmars.com

> Fail should take a return code too.

Good idea. Mind filing an enhancement request here?:
https://github.com/Abscissa/scriptlike/issues

Reply via email to