Can't get path to current script

[munificent]

When writing Dart scripts that read other files, it's helpful if you can identify that file with a path that's relative to the script itself. Right now, I don't think there's a way to get that in Dart. Instead, paths are always relative to where Dart was invoked from. This causes problems if you want to invoke the same script from different paths and have it still be able to reliably find files.

For example, I have a unit test (utils/tests/dartdoc/src/dartdoc_tests.dart) that wants to load a file in its same directory (dummy.dart). This unit test is run both through test.dart and frog's presubmit.py from different paths. Short of "let me see if it's here? no, how about here?" kind of hacks, I don't know of a clean way to support that.

[whesse]

Set owner to @whesse.
Added Area-Library, Accepted labels.

[DartBot]

This comment was originally written by [email protected]

---

Is that a duplicate of Issue #409?

[whesse]

Added Duplicate label.
Marked as being merged into #409.

[munificent]

Yes, sorry. I didn't find the other bug when I searched to see if this had already been reported.

[munificent]

After thinking about this some more, I don't believe this is the same issue as bug #­405. My understanding is that that bug is for:

  // a/b/main.dart
  #import('c/d/other.dart'); // or using #source
  main() => other();

  // c/d/other.dart
  other() => print(new Options().script);

  $ dart_bin ./a/b/main.dart
  a/b/main.dart

What I want here is the ability to get this:

  // a/b/main.dart
  #import('c/d/other.dart'); // or using #source
  main() => other();

  // c/d/other.dart
  other() => print(???);

  $ dart_bin ./a/b/main.dart
  a/b/c/d/other.dart

Something like FILE in C++, or file in Python.

My specific use case is I have a test script that needs to load some test data from a file. It knows where the file lives relative to itself. It does not know where it lives relative to where the user is invoking dart or relative to where the main script that ultimately #imports it is.

Re-opening this bug since as far as I can tell the issue is still valid.

I need this to work in frog too. Should I file a separate bug for that?

---

Added Triaged label.
Marked as being merged into #.

[whesse]

It seems to me that this would be a URI property of a library, saying where the library is loaded from. Is this part of reflection?

I don't see it as likely that a file that is included by #source would be able to find its location, but a library imported by #import may be able to know its URI.

---

cc @gbracha.
Removed Type-Defect, Area-Library labels.
Added Type-Enhancement, Area-Language labels.

[DartBot]

This comment was originally written by [email protected]

---

file / $0 are highly desirable. Please find a way to do this.

[gbracha]

I think this is really about the reflection API. Basically, what URI was used to import the library.

---

Added Accepted label.

[gbracha]

Unfortunately, the URI may not be available after deployment, tree-shaking etc. So we cannot rely on it. We may want a different solution to get at resources bundled with the application.

---

Added WontFix label.

[munificent]

The primary use case for this is command-line scripts that need to find other files relative to themselves, so I'm OK with it not being available for deployed or tree-shaken apps.

[nex3]

This is currently blocking Pub's ability to install packages from the SDK without forcing the user to manually specify the SDK path. Please re-open or suggest an alternative that will be available in the short term.

[gbracha]

So, if this is strictly for server side apps, why not write a native function?

[nex3]

Three reasons.

1. The feature is widely useful, and so makes sense as part of the core Dart distribution.
2. Distributing native code is much more difficult than distributing plain Dart code, which is a major consideration for the scripts and libraries that would be using this.
3. As far as I know, the embedding API doesn't have access to the path of the currently executing Dart file anyway.

[iposva-google]

Nathan, I do not understand why the executable() in the Options interface is not good enough for what you need.

[nex3]

The Options.executable returns the command-line invocation used to run the current script. What I'm asking for is a way to get the path of the current Dart file. Bob gave a good example above of the functional difference between the two.

In practical terms, the return values of Options.executable and Options.script only provide the ability to figure out where the Dart executable or the script entrypoint are. Neither of these suffice for all the use-cases of file. It's important that a library be able to figure out where it exists in the filesystem so that it can (for example) load resources from its installed directory.

[gbracha]

I'm trying to reconcile two positions here:

1. Comment 10 simply requests something that works on the command line.
2. Comment 13 argues it should be part of the core Dart distribution.

As I've said, the "path to the current library" has no meaning in a deployed application. More that that - it has no meaning for the Dart program at runtime - that is why an implementation is allowed to lose this structure during compilation.

In principle, one could require that a library have a property URI; however, that property would necessarily be misleading, as it has no reliable meaning in a deployed application. The first logically executed import that loads a library sets the URI property based on the (resolved) URI used in that import. In a deployed application, it might set the URI to the URI of the application as a whole (or to an error value, or null, or whatever).

Is this what you are asking for? Or do you actually expect to know what the path is for code in a sourced file? This variation is particularly unattractive.

Either way I can't say I'm comfortable adding such deployment-dependent functionality.

Your use case might be served by a native function in the VM. Perhaps the VM needs to add something to the embedder API.

[munificent]

As I've said, the "path to the current library" has no meaning in a deployed application.

Note that the request here isn't for the path to the current library, it's the path to the current file. For Pub, those two are equivalent since Pub doesn't use #source, but that isn't true for all possible use cases here.

Or do you actually expect to know what the path is for code in a sourced file?

That would be ideal, but I'd settle for path to the main library file.

Your use case might be served by a native function in the VM. Perhaps the VM needs to add something to the embedder API.

That's perfectly fine. This bug was merged with #­409, which is a library bug. Options.executable and Options.script are part of the embedder and not in the language proper.

This could be as simple as having an implicitly available top-level constant like FILE that's defined magically by the VM in every library the same way exit() is now.

[iposva-google]

Added this to the Later milestone.
Removed Area-Language label.
Added Area-VM label.

[munificent]

Re-opening since, I think, the discussion shows that this is still an open issue.

---

Added Triaged label.

[sethladd]

We have a Platform.script now.

Closing. Please reopen if that is not correct.

[nex3]

Platform.script isn't really enough here. It's not going to reliably point to the same thing in different contexts, and even if it did a Dart script really wants to be able to find paths relative to a library rather than relative to the entrypoint.

The best solution here is really a resource API like the one @lrhn is working on, though, so I'm fine with leaving this issue closed.

[sethladd]

The Resource API doesn't give you the path to your script, though.

It does allow you to load files/things with a package: URI and get the same resolution logic used when importing a Dart library via package:. Maybe that was the intent of this issue? If so, great!

[nex3]

It can give you the real URL for a package: URL, which allows libraries to find their own locations. If I can look up the real location of the package that contains my script, then I can get the real location of my script, too.

[sethladd]

@lrhn or @nex3 can you post a link to the CL? Thanks!

[nex3]

As far as I know, the API is still in the design stage.

[ianloic]

I would also like this please.

[0xff00ff]

+1 I want this feature. Is this can be done in some way?

[AkatQuas]

+1 Please.
I need tho configure the project root dynamically.
From node, we have __dirname__, could we have something similar in Dart ?

As for Directory.current, it points to the script calling directory, aka the current working directory in the terminal which is not the perfect solution.

[pacifio]

I am trying to load a natively compiled file and trying to run it using Process.run but when I use it as a library and get to another folder the path to the compiled file changes . I need the path of the original library here !

For example

This is mouse.dart:

import 'dart:io';

class _Mouse {
  void position() {
    if (Platform.isWindows) {
    } else {
      Directory.current = '../../bin/scripts/mouse/darwin/';
      Process.run('./mouse', ['position']).then((results) {
        print(results);
      });
    }
  }
}

final mouse = _Mouse();

The path to mouse file ( a compiled cli tool ) works if I execute this from mouse.dart but if I switch to example.dart:

import 'package:dart_autogui/dart_autogui.dart';

void main() {
  mouse.position();
}

This generates an error as follows :

Unhandled exception:
FileSystemException: Setting current working directory failed, path = '../../bin/scripts/mouse/darwin/' (OS Error: No such file or directory, errno = 2)
#0      _Directory.current= (dart:io/directory_impl.dart:79:7)
#1      Directory.current= (dart:io/directory.dart:196:18)
#2      _Mouse.position (package:demo/src/mouse/mouse.dart:7:17)
#3      main (file:///Users/adib/Desktop/open_source/demo/example/example.dart:4:9)
#4      _startIsolate.<anonymous closure> (dart:isolate-patch/isolate_patch.dart:301:19)
#5      _RawReceivePortImpl._handleMessage (dart:isolate-patch/isolate_patch.dart:168:12)

This should not happen . If I had something like __dirname like node . Please tell me how can I find the realtive path from the original library file / mouse.dart

[lumpidu]

Guys, it's 2025 and we still cannot get the absolute path of a file ? How should loading of native libraries supposed to work ? Should the user be forced to download these in an extra step ? Or getting hold of some other resources bundled with the dart package .... this is a standard feature in all major languages. And it's still not possible to get the absolute path of an installed package, whcih would be a workaround for installed packages at least.