On 2011-05-10 16:41, Andrei Alexandrescu wrote:
On 5/10/11 3:22 AM, Jacob Carlborg wrote:
On 2011-05-09 21:18, Andrei Alexandrescu wrote:
On 5/9/11 1:48 PM, Jacob Carlborg wrote:
On 2011-05-09 19:58, Andrei Alexandrescu wrote:
On 5/9/11 12:24 PM, Jacob Carlborg wrote:
I
have a function that gets the path of the current process:
http://dsource.org/projects/tango/attachment/ticket/1536/process.d
This links to a file attached to a Tango ticket but don't worry, I've
written the whole file myself and I intend to change the license to
the
Boost License. It's written with D1 (obviously) but it's very easy to
port to D2, the only dependencies are C functions.
Feel free to port it to D2 and use it in you're logging library if
you
want to.
I looked over the code, it's quite nice and clean. If you or anyone
else
would want to create a github pull request, the function would be a
valuable addition to std.process. Thanks Jacob for offering the
code to
Phobos!
What I think should change:
* Provide two overloads, one that attempts to reuse a buffer and one
that always returns a new string:
char[] getProcessPath(char[] buf) { ... }
static if (is(typeof(getProcessPath(null)) == char[]))
{
string getProcessPath() { return assumeUnique(getProcessPath(null)); }
}
Not sure I understand this.
The static if actually refers to the next point, which implies that
getProcessPath(char[]) may not exist on some systems.
The idea behind having two functions is to give a string to people who
just want a string without messing with buffers and all. The string has
the nice property that nobody can trample on it later.
Ok, I'll see if I can find the time to create a pull request out of
this. In what module should I put the function?
It looks like core.runtime already allows fetching the process path
name, so you need to figure out what the added value of your function
is.
Andrei
Are you referring to core.runtime.Runtime.args? That is not completely
reliable because:
* You can start a new process, with exec, and then pass in whatever you
want as the first argument to the process.
* If you start an application via a symlink wouldn't that refer to the
symlink instead of the actual executable?
* Also if you're running an application in a bundle on Mac OS X it would
refer to the bundle and not the actual executable, if I recall correctly.
I see. I'll defer ultimate decision on adding getProcessPath to Sean and
Walter. Probably with a little experimentation to clarify motivation,
getProcessPath is a worthy addition.
Thanks,
Andrei
Well, I only brought it up because I didn't know about Runtime.args.
--
/Jacob Carlborg
