Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix(runtime/ops): use argv[0] as exe-name if present in op_exec_path() #17468

Open
wants to merge 5 commits into
base: main
Choose a base branch
from

Conversation

jhheider
Copy link

Signed-off-by: Jacob Heider [email protected]

fixes #17464

should be fairly non-invasive (given it falls back to original code), but it could break some existing usages which might rely on the current (platform-inconsistent) behavior.

@CLAassistant
Copy link

CLAassistant commented Jan 18, 2023

CLA assistant check
All committers have signed the CLA.

@jhheider jhheider marked this pull request as draft January 19, 2023 00:03
@jhheider jhheider marked this pull request as ready for review January 19, 2023 01:11
@jhheider
Copy link
Author

Ok, this passes, and unfortunately we can't use PathBuf::canonicalize(), since it follows symlinks. So, using the URL module will have to remain to canonicalize the string only. But this does use argv[0] if present as exe_name, and joins it to cwd if it's relative (say, './foo').

The major risk here is changing behavior someone might be relying on. On linux, symlinks resolve to their target instead of themselves. The upside is that it will behave the same across platforms, now.

if argv0.is_absolute() {
argv0
} else {
std::env::current_dir().unwrap().join(argv0)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this will break if a user does Deno.chdir before calling this function. I wonder if we should follow Rust and leave this up to users to do? I'm not sure what's best.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm. That's a valid concern. I'll take a look at the execution environment and see if we can detect that.

Obviously, continuing to do what Rust does is one type of expectable behavior. It's unfortunate that different kernels do this differently. So, I'm torn between it's surprising because it's different from Rust or it's surprising because of environmental inconsistencies.

Obviously, we could use canonicalize() and always resolve the symlinks, but that feels like the worst version.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

use std::env;

fn main() {
  println!("{}", env::current_dir().unwrap().to_str().unwrap());
  env::set_current_dir("..").unwrap();
  println!("{}", env::current_dir().unwrap().to_str().unwrap());
}

Obviously does what you'd expect: "/Users/jacob\n/Users". And given that Deno.chdir() calls ops_chdir() > set_current_dir(), we can assume that your case will do that. So, a proper (full) solution would be to compute the value from argv[0] at invocation time, and cache it for the duration.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Other options could include skipping it for relative executions paths, or passing those out instead of resolving to absolute paths.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

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