You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@kballard pointed out in IRC that the argument types for std::run::Process::new and std::unstable::dynamic_library::open_external are wrong for a couple reasons:
They don't quite work like proper paths. Process::new wraps the syscall execvp, which looks in the current directory for "./foo", but in the PATH search paths for "foo". open_external uses dlopen, does the same thing with the DL_LIBRARY_PATH or DYLD_LIBRARY_PATH environment variables. Since Path::new automatically normalizes the paths, it turns a local reference of "./foo" into "foo", which changes the semantics of the syscall.
In the case of Process::new, it uses ~str for the program and arguments, but on Unix paths have no encoding.
In the case of dynamic_library::open_external, on Macs you can embed special dyld macros as in "@executable_path/../foo", which will look for a library relative to the location of the executable.
Because of these issues, I feel that the only real option is to have those methods take &[u8], or a trait that can produce one, like std::path::BytesContainer.