`Deno.execPath()` resolves symlink on Linux (doesn’t on Mac)

[mxcl]

$ echo "console.log(Deno.execPath())" > foo.ts
$ deno compile -A foo.ts
$ ./foo
/src/foo
ln -s foo bar
$ ./bar
/src/foo

On macOS the output is /src/bar. Resolving the symlink is not typical, many tools use the name of the symlink to change behavior, which is what we are trying to do.

I will happily PR a fix, just point me at the relevant source file and where I should add a regression test. Thanks.

$ deno --version
deno 1.29.2 (release, aarch64-unknown-linux-gnu)
v8 10.9.194.5
typescript 4.9.4

[lino-levan]

Hey @mxcl! Cool to see you contributing upstream.

Deno.execPath() is defined here

deno/runtime/js/30_os.js

Line 105 in 84e9794

function execPath() {

But that's just an op call to here in rust-land.

deno/runtime/ops/os/mod.rs

Line 70 in 84e9794

fn op_exec_path(state: &mut OpState) -> Result<String, AnyError> {

I'm not a huge rust guy, so that's about as far as I can investigate. If I had to guess, it's a bug in one of these lines:

let exe_url = Url::from_file_path(current_exe).unwrap();
let path = exe_url.to_file_path().unwrap();

into_string(path.into_os_string())

Which means it's probably a bug with Url from deno/core. It's technically possible that it's a bug with rust's std::env::current_exe() but I doubt it.

[jhheider]

Confirmed present in raw Rust:

https://gist.github.com/jhheider/b1dbc4ffe0e130414ca92c2a4c654d35

I wonder if the actually linux execution environment is resolving through. That wouldn't seem normal, since others tools can vary performance based on symlink.

[jhheider]

rust-lang/rust#43617 is responsive to the issue in question, but it's marked as completed in 2018 with an update to the documentation.

[jhheider]

One possible solution deno could use:

rivy/rs.coreutils@c457dfb

[lino-levan]

Confirmed present in raw Rust:

Did not see that one coming

rivy's workaround seems fine to use in deno imo. Would probably need a comment explaining why it is written that way though because that is super unclear.

[jhheider]

Perhaps I'll whip up a little PR since that change is small enough.

[jhheider]

^ should fix it for you, @mxcl.

root@d995fcee2c26:/deno# ./target/debug/deno compile -A foo.ts
Compile file:///deno/foo.ts
Emit foo
root@d995fcee2c26:/deno# ./foo
/deno/foo
root@d995fcee2c26:/deno# ln -s foo bar
root@d995fcee2c26:/deno# ./bar
/deno/bar

[mxcl]

great sleuthing @jhheider. So yes, this is in fact not deno or rust’s bug.

Something that seems true: if the end result is a shell script then the symlink is not resolved.

Thanks @lino-levan for the efforts you put in anyway, and apologies for the incorrect report.

[mxcl]

K, so I recently had reason to believe that, actually, my assessment was wrong and symlinks as arg0 should work on Linux, so I wrote a quick c program to test, and it prints the symlink. So I tried rust:

fn main() {
  let args: Vec<String> = std::env::args().collect();
  if let Some(program_name) = args.get(0) {
      println!("Program Name: {}", program_name);
  }
}

$ rustc foo.rs
$ ln -s foo bar
$ ./foo
Program Name: ./foo
$ ./bar
Program Name: ./bar

So indeed, this appears to be a deno bug. Reopening. Notably @jhheider tried to fix this already I believe: #17468

edit: and now I see that I misread jacob’s comment, he had it right all along 🤦🏻