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.

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;

http://dlang.org/phobos/std_path.html#.absolutePath

-Steve

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;
>
> http://dlang.org/phobos/std_path.html#.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.

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 :)

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.

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.

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

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.

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.

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