www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - full path to source file __FILE__

reply Jonathan Marler <johnnymarler gmail.com> writes:
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 ", ???);
}
Jul 21 2016
next sibling parent reply zabruk70 <sorry noem.ail> writes:
On Thursday, 21 July 2016 at 19:54:34 UTC, Jonathan Marler wrote:

 thisExePath won't work.


won't? what this means?

this work on my windows


import std.file: thisExePath;
import std.stdio: writeln;

void main()
{
   writeln(thisExePath());
}
Jul 21 2016
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Thursday, 21 July 2016 at 22:28:39 UTC, zabruk70 wrote:

 won't? what this means?


That gives the path to the .exe but he wants the path to the .d.

But why? I would think the current working directory is probably 
adequate and that's easy to get...
Jul 21 2016
parent reply Jonathan Marler <johnnymarler gmail.com> writes:
On Thursday, 21 July 2016 at 22:33:39 UTC, Adam D. Ruppe wrote:

 On Thursday, 21 July 2016 at 22:28:39 UTC, zabruk70 wrote:

 won't? what this means?


 That gives the path to the .exe but he wants the path to the .d.

 But why? I would think the current working directory is 
 probably adequate and that's easy to get...


I explain in the original post. Any ideas Adam? Thanks in advance.
Jul 21 2016
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Thursday, 21 July 2016 at 22:47:42 UTC, Jonathan Marler wrote:

 I explain in the original post. Any ideas Adam? Thanks in 
 advance.


But why does the batch script use it? Since you are rewriting 
anyway, maybe you can find an easier/better way to achieve the 
goal.
Jul 21 2016
parent reply Jonathan Marler <johnnymarler gmail.com> writes:
On Friday, 22 July 2016 at 01:52:57 UTC, Adam D. Ruppe wrote:

 On Thursday, 21 July 2016 at 22:47:42 UTC, Jonathan Marler 
 wrote:

 I explain in the original post. Any ideas Adam? Thanks in 
 advance.


 But why does the batch script use it? Since you are rewriting 
 anyway, maybe you can find an easier/better way to achieve the 
 goal.


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?
Jul 21 2016
parent reply Jacob Carlborg <doob me.com> writes:
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
Jul 21 2016
parent reply Jonathan Marler <johnnymarler gmail.com> writes:
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.
Jul 22 2016
parent reply Kagamin <spam here.lot> writes:
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?
Jul 22 2016
parent Adam D. Ruppe <destructionator gmail.com> writes:
On Friday, 22 July 2016 at 10:51:57 UTC, Kagamin wrote:

 Don't just ignore Adam's question :)


eh he answered it.

On Windows, it is somewhat common for things to be loaded or 
modified (especially on older versions when these were still 
writable...) from the program's directory. Its support files are 
all put together with the exe.

He's trying to make a "script" that is run with rdmd that 
pretends to work just like an exe and works with files around it.
Jul 22 2016
prev sibling next sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 7/21/16 3:54 PM, 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 ", ???);
 }


Sure seems like an unwanted limitation.

rdmd does forward all dmd options, but there isn't really an option to 
say "put the exe in the source path".

You should file an enhancement.

-Steve
Jul 21 2016
next sibling parent Jonathan Marler <johnnymarler gmail.com> writes:
On Thursday, 21 July 2016 at 22:39:45 UTC, Steven Schveighoffer 
wrote:

 On 7/21/16 3:54 PM, 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 ", ???);
 }


 Sure seems like an unwanted limitation.

 rdmd does forward all dmd options, but there isn't really an 
 option to say "put the exe in the source path".

 You should file an enhancement.

 -Steve


An option for rdmd would be good, but then requires the user to 
call rdmd in a particular way. It doesnt allow the script itself 
know where it lives, which is needed in my case.
Jul 21 2016
prev sibling parent reply Jonathan M Davis via Digitalmars-d-learn writes:
On Thursday, July 21, 2016 18:39:45 Steven Schveighoffer via Digitalmars-d-
learn wrote:

 On 7/21/16 3:54 PM, 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 ", ???);

 }


 Sure seems like an unwanted limitation.

 rdmd does forward all dmd options, but there isn't really an option to
 say "put the exe in the source path".

 You should file an enhancement.


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
Jul 21 2016
parent Jonathan Marler <johnnymarler gmail.com> writes:
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.
Jul 21 2016
prev sibling next sibling parent Jonathan M Davis via Digitalmars-d-learn writes:
On Thursday, July 21, 2016 19:54:34 Jonathan Marler via Digitalmars-d-learn 
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 ", ???);
 }


Well, while it might not be what you want, the obvious solution is to just
compile it as an executable and put that where you want rather than making
it a script.

- Jonathan M Davis
Jul 21 2016
prev sibling next sibling parent reply fdgdsgf <sdfhsdh fgfh.fgh> writes:
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 ?
Jul 21 2016
parent reply Jonathan Marler <johnnymarler gmail.com> writes:
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.
Jul 22 2016
next sibling parent reply sdhdfhed <sdhdfhedsmd jjsdg.thy> writes:
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 !
Jul 22 2016
next sibling parent sdhdfhed <sdhdfhedsmd jjsdg.thy> writes:
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.
Jul 22 2016
prev sibling parent reply Jonathan Marler <johnnymarler gmail.com> writes:
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.
Jul 22 2016
parent reply sdhdfhed <sdhdfhedsmd jjsdg.thy> writes:
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.
Jul 22 2016
parent reply Jonathan Marler <johnnymarler gmail.com> writes:
On Friday, 22 July 2016 at 09:37:24 UTC, sdhdfhed wrote:

 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.


Again that's Walter's call.  The __FILE__ trait seems to be used 
most useful for error messages.  I could see him wanting it to be 
a relative path sometimes and an absolute one other times.  By 
redefining it to always be absolute would solve this problem, but 
might make others things harder.  I'm not particularly for or 
against either solution (not sure why you're trying to convince 
me of this one), that would be up to the owners of the language :)
Jul 22 2016
parent reply sdhdfhed <sdhdfhedsmd jjsdg.thy> writes:
On Friday, 22 July 2016 at 14:02:03 UTC, Jonathan Marler wrote:

 The __FILE__ trait seems to be used most useful for error 
 messages.


Another usage is for testing parsers or string functions directly 
on the source. E.g in "devel" mode the main function

void main(string[] args)
{
     version(devel)
     {
         // dont mess with params, use the text in source to catch 
most simple bugs.
         File f = File(__FILE__, "r");
     }
     else
     {
         // load using args
     }
}


 I could see him wanting it to be a relative path sometimes and 
 an absolute one other times.  By redefining it to always be 
 absolute would solve this problem,


I'm for this, always absolute. Eventually forced by a new switch: 
default behavior is not changed.
Jul 22 2016
parent reply Jonathan Marler <johnnymarler gmail.com> writes:
On Friday, 22 July 2016 at 19:13:31 UTC, sdhdfhed wrote:

 On Friday, 22 July 2016 at 14:02:03 UTC, Jonathan Marler wrote:

 The __FILE__ trait seems to be used most useful for error 
 messages.


 Another usage is for testing parsers or string functions 
 directly on the source. E.g in "devel" mode the main function

 void main(string[] args)
 {
     version(devel)
     {
         // dont mess with params, use the text in source to 
 catch most simple bugs.
         File f = File(__FILE__, "r");
     }
     else
     {
         // load using args
     }
 }


 I could see him wanting it to be a relative path sometimes and 
 an absolute one other times.  By redefining it to always be 
 absolute would solve this problem,


 I'm for this, always absolute. Eventually forced by a new 
 switch: default behavior is not changed.


Actually I realized if __FILE__ was always absolute, then all 
your exception messages would contain the full path of the file 
it was thrown from on the machine it was compiled on. This would 
be quite odd. Both a relative and absolute version are useful in 
different cases.
Jul 22 2016
parent Jonathan M Davis via Digitalmars-d-learn writes:
On Friday, July 22, 2016 19:28:05 Jonathan Marler via Digitalmars-d-learn 
wrote:

 Actually I realized if __FILE__ was always absolute, then all
 your exception messages would contain the full path of the file
 it was thrown from on the machine it was compiled on. This would
 be quite odd.


In some cases, it could also be viewed as a security risk. For instance, on
*nix systems, it would almost certainly give away the username of the user
that built it.

Also, it would result in needlessly long error messages when exceptions were
thrown, which could impact performance as well as making log files that much
more annoying.

I'm definietly inclined to think that making __FILE__ absolute would be a
mistake. Maybe something else like __FILE_ABSOLUTE__ would be okay, but in
this particular case, I'd argue that you should just not make it a script if
you need additional files that are next to it rather than in a known place.
And as far as your example of build files goes, it's normal to have to run
stuff like that in the directory where it lives (e.g. that's what happens
with make), so while I understand that it may be annoying, I don't think
that it's a compelling use case for changing what __FILE__ does.

- Jonathan M Davis
Jul 22 2016
prev sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 7/22/16 3:47 AM, Jonathan Marler 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 you combine it with current working directory, this should give you 
the full path.

Looks like std.path gives you a mechanism, I think this should work:

import std.path;
auto p = __FILE__.absolutePath;



-Steve
Jul 22 2016
parent reply Jonathan Marler <johnnymarler gmail.com> writes:
On Friday, 22 July 2016 at 13:30:10 UTC, Steven Schveighoffer 
wrote:

 On 7/22/16 3:47 AM, Jonathan Marler 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 you combine it with current working directory, this should 
 give you the full path.

 Looks like std.path gives you a mechanism, I think this should 
 work:

 import std.path;
 auto p = __FILE__.absolutePath;



 -Steve


That doesn't work in the example I provided:

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

Since you are running the script from "anypath", the information 
that clean.d exists at /somedir is lost.  The last component to 
know where the file was found is the compiler itself.
Jul 22 2016
parent reply Kagamin <spam here.lot> writes:
On Friday, 22 July 2016 at 13:50:55 UTC, Jonathan Marler wrote:

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


So for command rdmd /somedir/clean.d what __FILE__ contains? LDC 
tells me the same path as specified on the command line, and that 
is specified relative to current directory, where the compiler is 
called, so absolutePath(__FILE__) should give the right result.
Jul 22 2016
parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 7/22/16 2:43 PM, Kagamin wrote:

 On Friday, 22 July 2016 at 13:50:55 UTC, Jonathan Marler wrote:

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


 So for command rdmd /somedir/clean.d what __FILE__ contains? LDC tells
 me the same path as specified on the command line, and that is specified
 relative to current directory, where the compiler is called, so
 absolutePath(__FILE__) should give the right result.


The issue which is not being expressed completely by Jonathan, is that 
rdmd caches the build.

So if I run the script from one directory, then cd elsewhere, it has the 
same __FILE__ as before, but the cwd has moved. So it won't work.

I had assumed rdmd would rebuild, but it doesn't.

-Steve
Jul 22 2016
parent Jonathan Marler <johnnymarler gmail.com> writes:
On Friday, 22 July 2016 at 19:23:30 UTC, Steven Schveighoffer 
wrote:

 On 7/22/16 2:43 PM, Kagamin wrote:

 On Friday, 22 July 2016 at 13:50:55 UTC, Jonathan Marler wrote:

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


 So for command rdmd /somedir/clean.d what __FILE__ contains? 
 LDC tells
 me the same path as specified on the command line, and that is 
 specified
 relative to current directory, where the compiler is called, so
 absolutePath(__FILE__) should give the right result.


 The issue which is not being expressed completely by Jonathan, 
 is that rdmd caches the build.

 So if I run the script from one directory, then cd elsewhere, 
 it has the same __FILE__ as before, but the cwd has moved. So 
 it won't work.

 I had assumed rdmd would rebuild, but it doesn't.

 -Steve


Thanks for pointing this out, somehow I overlooked this use case.
Jul 22 2016
prev sibling next sibling parent Martin Tschierschke <mt smartdolphin.de> writes:
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


What about using a wrapper around rdmd, so the program is 
executed with an
additional parameter or an environment variable containing 
"FULL_PATH".

When I started with D, I "accidentaly" wrote my own replacement 
script for rdmd
compiling xyz.d with dmd to xyz or calling xyz depending on the 
modification times of the files.

Regards mt.
Jul 23 2016
prev sibling parent reply Jonathan Marler <johnnymarler gmail.com> writes:
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 ", ???);
 }


For others who may see this thread, the __FULL_FILE_PATH__ 
special trait was added to the dmd compiler with this PR: 
https://github.com/dlang/dmd/pull/5959

At the time of this post, the latest released version of D is 
2.071.1, so this trait should be available on any release after 
that.
Jul 27 2016
parent reply DigitalDesigns <DigitalDesigns gmail.com> writes:
On Wednesday, 27 July 2016 at 13:58:22 UTC, Jonathan Marler 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 ", ???);
 }


 For others who may see this thread, the __FULL_FILE_PATH__ 
 special trait was added to the dmd compiler with this PR: 
 https://github.com/dlang/dmd/pull/5959

 At the time of this post, the latest released version of D is 
 2.071.1, so this trait should be available on any release after 
 that.


Except it doesn't?

auto x(string fp = __FULL_FILE_PATH__)()
{
    pragma(msg, fp);
}

?
May 29 2018
next sibling parent reply =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 05/29/2018 02:34 PM, DigitalDesigns wrote:
  > auto x(string fp = __FULL_FILE_PATH__)()

 {
     pragma(msg, fp);
 }
 
 ?


__FILE_FULL_PATH__

   https://dlang.org/spec/expression#specialkeywords

Ali
May 29 2018
parent DigitalDesigns <DigitalDesigns gmail.com> writes:
On Tuesday, 29 May 2018 at 21:41:37 UTC, Ali Çehreli wrote:

 On 05/29/2018 02:34 PM, DigitalDesigns wrote:
  > auto x(string fp = __FULL_FILE_PATH__)()

 {
     pragma(msg, fp);
 }
 
 ?


 __FILE_FULL_PATH__

   https://dlang.org/spec/expression#specialkeywords

 Ali


Lol, thanks:
May 29 2018
prev sibling parent Steven Schveighoffer <schveiguy yahoo.com> writes:
On 5/29/18 5:34 PM, DigitalDesigns wrote:

 On Wednesday, 27 July 2016 at 13:58:22 UTC, Jonathan Marler 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 ", ???);
 }


 For others who may see this thread, the __FULL_FILE_PATH__ special 
 trait was added to the dmd compiler with this PR: 
 https://github.com/dlang/dmd/pull/5959

 At the time of this post, the latest released version of D is 2.071.1, 
 so this trait should be available on any release after that.


 
 Except it doesn't?
 
 auto x(string fp = __FULL_FILE_PATH__)()
 {
     pragma(msg, fp);
 }
 
 ?


__FILE_FULL_PATH__, not __FULL_FILE_PATH__ (yes, it was wrong in the 
post you quoted).

In addition, you must instantiate the template:

void main()
{
     x();
}

-Steve
May 29 2018