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

work around current_dir differences #16

Closed
oconnor663 opened this issue Nov 18, 2016 · 1 comment
Closed

work around current_dir differences #16

oconnor663 opened this issue Nov 18, 2016 · 1 comment

Comments

@oconnor663
Copy link
Owner

See rust-lang/rust#37868

This is probably worth testing noting in the implementation notes. I think it will affect Python too.

@oconnor663
Copy link
Owner Author

We probably need to absolutify paths to make this work right. The big downside is that absolutifying paths can fail. The current directory might not exist anymore, or some unusual filesystem type might not support canonicalize. If we want to minimize our calls to canonicalize as much as possible, the logic probably needs to be:

  • If we're a cmd and not an sh (because sh always runs in the new dir)
  • and the dir field is set
  • and the program name either 1) contains directory separators or 2) is a Path
  • and parsing the name as a Path and calling is_relative returns true
  • then and only then absolutify the program name before calling it.

That set of limitations would mean that probably the vast majority of commands would succeed, even if they were in a weird filesystem, because they wouldn't even attempt to canonicalize. (However, there's some downside to making this error conditional on unrelated-seeming tiny changes like using dir. There could be some upside to forcing canonicalize more frequently, just to be consistent?)

Also worth being aware: the path by which a program is called is visible to the program as argv[0]. Absolutifying things might break certain programs. But on the other hand, in the conditions above, most programs would almost certainly be broken anyway. (Unless they were explicitly relying on the interpret-after-cd current Unix behavior.)

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

No branches or pull requests

1 participant