I've got some batch scripts I wanted to convert to D.  I'd like users to run them using rdmd, so it's obvious where the source code lives and easy to modify.  The problem is that the batch scripts I want to convert rely on the %~dp0 variable, which contains the path to the batch script itself.  Note that this variable is different then the current directory.  I haven't been able to find a nice way to do this in D.  (Note that thisExePath won't work because rdmd compiles the code to a temporary directory, which makes sense.)

Having known about the special __FILE__ and __LINE__ traits, I figured there might be a trait for the file directory as well, but it appears there is none.  I'd like to see what people think about adding a new trait for this.  Maybe something like __FILE_DIR__?  This would contain the directory of the source-code file it appears in.  Also if this trait was added, one could argue that a trait containing the path and the filename should also be added, maybe something like __FILE_FULL_PATH__?


P.S. If you know of an existing solution to this problem please let me know.

On 22/07/2016 2:08 PM, Jonathan Marler wrote:
> I've got some batch scripts I wanted to convert to D.  I'd like users to
> run them using rdmd, so it's obvious where the source code lives and
> easy to modify.  The problem is that the batch scripts I want to convert
> rely on the %~dp0 variable, which contains the path to the batch script
> itself.  Note that this variable is different then the current
> directory.  I haven't been able to find a nice way to do this in D.
> (Note that thisExePath won't work because rdmd compiles the code to a
> temporary directory, which makes sense.)
>
> Having known about the special __FILE__ and __LINE__ traits, I figured
> there might be a trait for the file directory as well, but it appears
> there is none.  I'd like to see what people think about adding a new
> trait for this.  Maybe something like __FILE_DIR__?  This would contain
> the directory of the source-code file it appears in.  Also if this trait
> was added, one could argue that a trait containing the path and the
> filename should also be added, maybe something like __FILE_FULL_PATH__?
>
>
> P.S. If you know of an existing solution to this problem please let me
> know.

Temporary work around:
Write a program that on calls to rdmd but before that it appends an enum called that, on after it removes it by shrinking the file.

On Friday, 22 July 2016 at 04:10:38 UTC, rikki cattermole wrote:
> On 22/07/2016 2:08 PM, Jonathan Marler wrote:
>> P.S. If you know of an existing solution to this problem please let me
>> know.
>
> Temporary work around:
> Write a program that on calls to rdmd but before that it appends an enum called that, on after it removes it by shrinking the file.

Interesting solution.  It definitely has a "hacky" feel but I suppose it would work.  I decided to take a stab at implementing the feature and have a Pull Request here.

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

On Friday, 22 July 2016 at 02:08:44 UTC, Jonathan Marler wrote:
> I've got some batch scripts I wanted to convert to D.  I'd like users to run them using rdmd, so it's obvious where the source code lives and easy to modify.  The problem is that the batch scripts I want to convert rely on the %~dp0 variable, which contains the path to the batch script itself.  Note that this variable is different then the current directory.  I haven't been able to find a nice way to do this in D.  (Note that thisExePath won't work because rdmd compiles the code to a temporary directory, which makes sense.)
>
> Having known about the special __FILE__ and __LINE__ traits, I figured there might be a trait for the file directory as well, but it appears there is none.  I'd like to see what people think about adding a new trait for this.  Maybe something like __FILE_DIR__?  This would contain the directory of the source-code file it appears in.  Also if this trait was added, one could argue that a trait containing the path and the filename should also be added, maybe something like __FILE_FULL_PATH__?
>
>
> P.S. If you know of an existing solution to this problem please let me know.

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.

On Wednesday, 27 July 2016 at 13:59:23 UTC, Jonathan Marler wrote:
> On Friday, 22 July 2016 at 02:08:44 UTC, Jonathan Marler wrote:
>> [...]
>
> 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.

Plz don't forget to propose a PR for the specifications too. The serious way of doing things include this step.

https://dlang.org/spec/lex.html
https://github.com/dlang/dmd/blob/master/changelog.dd

On Wednesday, 27 July 2016 at 14:07:23 UTC, lkfsdg wrote:
> On Wednesday, 27 July 2016 at 13:59:23 UTC, Jonathan Marler wrote:
>> On Friday, 22 July 2016 at 02:08:44 UTC, Jonathan Marler wrote:
>>> [...]
>>
>> 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.
>
> Plz don't forget to propose a PR for the specifications too. The serious way of doing things include this step.
>
> https://dlang.org/spec/lex.html
> https://github.com/dlang/dmd/blob/master/changelog.dd

Yes thank you for the reminder.  It's good to know that people understand the value of documentation.

On Wednesday, 27 July 2016 at 13:59:23 UTC, Jonathan Marler wrote:

> 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

__DIR__ will be useful, I think. Just directory name, without file name.

On Thursday, 28 July 2016 at 00:42:11 UTC, crimaniak wrote:
> On Wednesday, 27 July 2016 at 13:59:23 UTC, Jonathan Marler wrote:
>
>> 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
>
> __DIR__ will be useful, I think. Just directory name, without file name.

Sure if others thought it was a good idea.  I wouldn't really mind typing __FILE_FULL_PATH__.dirName, but others might find __DIR__ useful.  Good thing is that it could be added to the standard library (wouldn't have to change the compiler) now that __FULL_FILE_PATH__ has been added.  I'm guessing it would have to be a function like this:

auto __DIR__(string fileFullPath = __FILE_FULL_PATH__) pure
{
    return fileFullPath.dirName;
}

May or may not be useful enough to be added to druntime or phobos, I'll let someone else decide that :)

On Thursday, 28 July 2016 at 06:21:06 UTC, Jonathan Marler wrote:
> auto __DIR__(string fileFullPath = __FILE_FULL_PATH__) pure
> {
>     return fileFullPath.dirName;
> }

Doesn't work, I don't think you can wrap such things ( __FILE__ and such ):

import std.stdio;

int main()
{
  printNormal();
  printWrapped();
  return 0;
}

void printNormal(int line = __LINE__)
{
  writefln("%s", line);
}

void printWrapped(int line = __MY_LINE__)
{
  writefln("%s", line);
}

// wrapped version
int __MY_LINE__(int line = __LINE__)
{
  return line;
}

$ rdmd demo.d
5
15  (should be 6!)

Thus, the suggested implementation of __DIR__ would behave very differently from a builtin one. I'm not saying we need a builtin one, however, it might not be a good idea to name it this way.

By the way, I really think __FILE_FULL_PATH__ should be a rdmd feature, not dmd.

rdmd could set an environment variable "RDMD_FULL_PATH" or something like this (replacing argv[0]), instead of potentially making the compilation depend on the working copy location on disk...