On Thursday, 21 July 2016 at 22:57:06 UTC, Jonathan M Davis wrote:
> On Thursday, July 21, 2016 18:39:45 Steven Schveighoffer via Digitalmars-d- learn wrote:
>> [...]
>
> It would be pretty terrible actually to put the executable in the source path, and in many cases, the user wouldn't even have the permissions for it. For instance, what if the script were in /usr/local/bin? They won't have the permissions for the executable to end up there, and it would just cause a bunch of clutter in /usr/local/bin, since you'd get a new executable every time it decided that it needed to rebuild it (and you wouldn't want it to delete the executable every time, otherwise it would have to rebuild it every time, making it so that it would _always_ have to compile your script when it runs instead of just sometimes). Right now, the executable ends up in a temp directory, which makes a lot of sense.
>
> Maybe it would make sense to have such a flag for very rare cases, but in general, it seems like a terrible idea.
>
> - Jonathan M Davis

I agree this isn't a very good solution for the problem at hand.  Putting the executable in a temporary directory makes sense in any cases I can think of. I posted an idea for another potential solution (http://forum.dlang.org/thread/cmydxneeghtjqjroxpld@forum.dlang.org), please let me know your thoughts.  Thanks.

On Thursday, 21 July 2016 at 19:54:34 UTC, Jonathan Marler wrote:
> Is there a way to get the full path of the current source file? Something like:
>
> __FILE_FULL_PATH__
>
> I'm asking because I'm rewriting a batch script in D, meant to be ran with rdmd.  However, the script needs to know it's own path.  The original batch script uses the %~dp0 variable for this, but I'm at a loss on how to do this in D.  Since rdmd compiles the executable to the %TEMP% directory, thisExePath won't work.
>
> BATCH
> -----
> echo "Directory of this script is " %~dp0
>
>
> DLANG
> -----
> import std.stdio;
> int main(string[] args) {
>     writeln("Directory of this script is ", ???);
> }

What's wrong with __FILE__.dirName ?

On 2016-07-22 04:24, Jonathan Marler wrote:

> The script depends on other files relative to where it exists on the
> file system.  I couldn't think of a better design to find these files
> then knowing where the script exists, can you?

What kind of files are we talking about. Resource files, config files? Are they static? For static resource files you can bundle them in the executable with a string import. For config files it might be better to store it in a completely different directory, like the user's home directory. This actually depends on what kind of config files and the operating system.

-- 
/Jacob Carlborg

On Friday, 22 July 2016 at 05:41:00 UTC, fdgdsgf wrote:
> On Thursday, 21 July 2016 at 19:54:34 UTC, Jonathan Marler wrote:
>> Is there a way to get the full path of the current source file? Something like:
>>
>> __FILE_FULL_PATH__
>>
>> I'm asking because I'm rewriting a batch script in D, meant to be ran with rdmd.  However, the script needs to know it's own path.  The original batch script uses the %~dp0 variable for this, but I'm at a loss on how to do this in D.  Since rdmd compiles the executable to the %TEMP% directory, thisExePath won't work.
>>
>> BATCH
>> -----
>> echo "Directory of this script is " %~dp0
>>
>>
>> DLANG
>> -----
>> import std.stdio;
>> int main(string[] args) {
>>     writeln("Directory of this script is ", ???);
>> }
>
> What's wrong with __FILE__.dirName ?

It's kinda weird, sometimes I've noticed that the __FILE__ keyword is an absolute path, and sometimes it isn't.  If it was always an absolute path, that would work.  I decided to take a stab at implementing this in the dmd compiler:

https://github.com/dlang/dmd/pull/5959

It adds a __FILE_FULL_PATH__ trait which would solve the issue.

On Friday, 22 July 2016 at 06:45:58 UTC, Jacob Carlborg wrote:
> On 2016-07-22 04:24, Jonathan Marler wrote:
>
>> The script depends on other files relative to where it exists on the
>> file system.  I couldn't think of a better design to find these files
>> then knowing where the script exists, can you?
>
> What kind of files are we talking about. Resource files, config files? Are they static? For static resource files you can bundle them in the executable with a string import. For config files it might be better to store it in a completely different directory, like the user's home directory. This actually depends on what kind of config files and the operating system.

I suppose I should have been more specific.  The script actually operates on the filesystem relative to where it lives.  It copies files, modifies directories, etc.  It is meant to be ran from any directory, but is only meant to modify the filesystem relative to where it lives.  Take a simple example of a clean script:

/somedir/clean.d
/somedir/build

Say clean.d is meant to remove the build directory that lives in the same path as the clean.d script itself.

shell/anypath> rdmd /somedir/clean.d
Removing /somedir/build...

It's important to remember that the clean.d script is ran with rdmd, and that it is meant to be called from any directory.  Since it's ran with rdmd, the thisExePath won't give you the right directory, and since you can call it from any directory, you also can't use the current directory.  As you can see, what you really want to know is where the script itself lives.

On Friday, 22 July 2016 at 07:47:14 UTC, Jonathan Marler wrote:
> On Friday, 22 July 2016 at 05:41:00 UTC, fdgdsgf wrote:
>> What's wrong with __FILE__.dirName ?
>
> It's kinda weird, sometimes I've noticed that the __FILE__ keyword is an absolute path, and sometimes it isn't.  If it was always an absolute path, that would work.  I decided to take a stab at implementing this in the dmd compiler:
>
> https://github.com/dlang/dmd/pull/5959
>
> It adds a __FILE_FULL_PATH__ trait which would solve the issue.

Personally I've never seen a relative __FILE__. Is this an issue that's confirmed ?

I mean  that it would be better to fix __FILE__ so that its result is always absolute then. I think that such a "PPR" (punk-pull-request) has 0% chance of being accepted, especially since it adds a special keyword !

On Friday, 22 July 2016 at 07:57:35 UTC, sdhdfhed wrote:
> On Friday, 22 July 2016 at 07:47:14 UTC, Jonathan Marler wrote:
>> [...]
>
> Personally I've never seen a relative __FILE__. Is this an issue that's confirmed ?
>
> I mean  that it would be better to fix __FILE__ so that its result is always absolute then. I think that such a "PPR" (punk-pull-request) has 0% chance of being accepted, especially since it adds a special keyword !

make a PR that expands the sources passed to the dmd to their absolute name. This is more likely to fix your issue and to be accepted.

On Friday, 22 July 2016 at 07:57:35 UTC, sdhdfhed wrote:
> On Friday, 22 July 2016 at 07:47:14 UTC, Jonathan Marler wrote:
>> On Friday, 22 July 2016 at 05:41:00 UTC, fdgdsgf wrote:
>>> What's wrong with __FILE__.dirName ?
>>
>> It's kinda weird, sometimes I've noticed that the __FILE__ keyword is an absolute path, and sometimes it isn't.  If it was always an absolute path, that would work.  I decided to take a stab at implementing this in the dmd compiler:
>>
>> https://github.com/dlang/dmd/pull/5959
>>
>> It adds a __FILE_FULL_PATH__ trait which would solve the issue.
>
> Personally I've never seen a relative __FILE__. Is this an issue that's confirmed ?
>
> I mean  that it would be better to fix __FILE__ so that its result is always absolute then. I think that such a "PPR" (punk-pull-request) has 0% chance of being accepted, especially since it adds a special keyword !

It's definitely confirmed.  And now that I've walked through the source code, I see that it wasn't implemented to be an absolute path, it just happens to be some of the time depending on how the file is found.  I'm sure Walter will have an opinion as to what solution he prefers.  Either redefining the __FILE__ trait or adding a new one. He's communicating fixes to the PR on github so that a good sign.  We'll see.

On Friday, 22 July 2016 at 08:36:37 UTC, Jonathan Marler wrote:
> On Friday, 22 July 2016 at 07:57:35 UTC, sdhdfhed wrote:
>> On Friday, 22 July 2016 at 07:47:14 UTC, Jonathan Marler wrote:
>>> On Friday, 22 July 2016 at 05:41:00 UTC, fdgdsgf wrote:
>>>> What's wrong with __FILE__.dirName ?
>>>
>>> It's kinda weird, sometimes I've noticed that the __FILE__ keyword is an absolute path, and sometimes it isn't.  If it was always an absolute path, that would work.  I decided to take a stab at implementing this in the dmd compiler:
>>>
>>> https://github.com/dlang/dmd/pull/5959
>>>
>>> It adds a __FILE_FULL_PATH__ trait which would solve the issue.
>>
>> Personally I've never seen a relative __FILE__. Is this an issue that's confirmed ?
>>
>> I mean  that it would be better to fix __FILE__ so that its result is always absolute then. I think that such a "PPR" (punk-pull-request) has 0% chance of being accepted, especially since it adds a special keyword !
>
> It's definitely confirmed.  And now that I've walked through the source code, I see that it wasn't implemented to be an absolute path, it just happens to be some of the time depending on how the file is found.  I'm sure Walter will have an opinion as to what solution he prefers.  Either redefining the __FILE__ trait or adding a new one. He's communicating fixes to the PR on github so that a good sign.  We'll see.

Yes, i've seen he 's started to review.

I don't know if you've seen my other suggestion but another solution would be to force relative fnames passed to the compiler to be translated to absolute. This is also why I've never seen a relative __FILE__. The build tool I use always does the expansion in intern before calling the compiler.

On Friday, 22 July 2016 at 07:53:17 UTC, Jonathan Marler wrote:
> It's important to remember that the clean.d script is ran with rdmd, and that it is meant to be called from any directory.  Since it's ran with rdmd, the thisExePath won't give you the right directory, and since you can call it from any directory, you also can't use the current directory.  As you can see, what you really want to know is where the script itself lives.

Don't just ignore Adam's question :)
https://dlang.org/phobos/std_path.html#.absolutePath
https://dlang.org/phobos/std_file.html#.getcwd - why this won't work for you?