On Monday, 25 February 2013 at 21:06:54 UTC, Vladimir Panteleev
wrote:
On Monday, 25 February 2013 at 20:06:19 UTC, Lars T.
Kyllingstad wrote:
That is also incredibly obscure. I'd venture a guess that
only ~10% of D's user base have even heard of Lynx. Everyone
knows firefox, and will understand what the example is
supposed to illustrate. (I admit that the ls/grep examples
will also be rather incomprehensible to someone not familiar
with the *NIX command line, and I will replace them with
something else. The D toolchain, as you suggest below, is a
very good idea.)
I still think using Firefox is a bad idea, but I've already
presented my arguments.
BTW, browse() should never have been added to std.process, in
my opinion. Maybe to some other utility module, but then it
should at least be done right, and be properly documented.
What would you improve about it?
1. I would document it properly.
2. As long as it runs in the background, I would return some kind
of process ID from it. (Yes, most browsers today may just signal
another instance to open a new tab and then return, but would be
surprised if they *all* do.)
(3. Maybe put it in a different module, I'm not sure.)
Also, and this is of course extremely subjective, it just looks
out of place and very much "alone". Where is
writeEmailInDefaultClient(address)? Where is
openInAssociatedApp(file)?
I have no opinion on its location in Phobos, but std.process is
the most fitting one if you don't consider creating a new
module.
Maybe.
[...]
Then, a end-user tries setting the config variable to a path
that contains spaces, and everything breaks. Wrapping the
path in quotes does not help either. Due to the way the
function is designed, it is IMPOSSIBLE for the end-user to
configure the application to launch a program located at a
path containing spaces. To end-users, this comes off as a
classical problem in badly written applications that don't
handle command-line escaping properly.
Exposing the specifics of whatever programming language you
are using to the end user?
I don't understand what you mean here. It's not exposing any
specifics if you don't implement anything in a way specific to
D.
You pass a string directly from a config file into a rather
low-level function in the programming language's standard library
without any kind of validation.
[...]
You almost have me convinced that the single-string non-shell
functions must go. In the case of pipeProcess() and
execute(), pipeShell() and shell() do the same job, with
(arguably, still) less surprises. Maybe it would then be a
good idea to add a spawnShell() function to go with
spawnProcess().
How about something that converts a ProcessPipes instance into
a Tuple!(int, "status", string, "output") as returned by shell?
Then you could do e.g.
auto result = shell("command").collectOutput();
// use result.status or result.output
That's pretty elegant. :)
Lars
