`spawn("sub/prog")` of a file that is missing or not executable reports a PATH search
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 83/100
Research direction
Start in spawn.rs at resolve and the call site around line 89, then read the test a_program_with_a_directory_part_is_found_from_the_working_directory. Add adjacent tests for a non-executable file and a missing file under a directory path. Done when each error reports the underlying permission or missing-file cause instead of a PATH search.
Written by the indexing model from the issue text.
Description
What happens. #592 made a program name with a directory part resolve from the working directory. On the error path it still falls back to the old PATH search, so the reason shown is wrong:
program in dir |
termlens Error::Spawn reason |
std::process::Command |
|---|---|---|
sub/prog, mode 644 |
Unable to spawn sub/prog because: No viable candidates found in PATH … |
Permission denied (os error 13) |
sub/missing |
the same PATH message | No such file or directory (os error 2) |
./sub/prog, mode 644 |
"… because it is not executable" (correct) | — |
Cause. resolve (spawn.rs:212-219) returns None when dir/sub/prog is not runnable. spawn.rs:89 then hands sub/prog to portable-pty, which searches only PATH.
Why it matters. The common CI case is target/debug/app downloaded as an artifact without its executable bit. Error::Spawn promises "the reason the OS gave", but a PATH miss sends the reader looking in the wrong place.
Fix. When a name with a directory part exists in dir, return it even if it is not runnable. The exec then fails with EACCES and explain() reports it. For a missing file, report ENOENT against dir/sub/prog instead of searching PATH.
Done when both cases name the real cause, with tests beside a_program_with_a_directory_part_is_found_from_the_working_directory.
- Dominant language
- Rust
- Stars
- 28
- Forks
- 24
- Avg merge
- 11h 23m
- Merged PRs (30d)
- 42
Getting set up
- No Dockerfile or Docker Compose file
- Has a pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from vyncint/termlens
-
documentation good first issue
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
Maintainers usually reply within 1 day
-
documentation good first issue
Difficulty 1/5 Under an hour Newbie friendliness 95/100
Maintainers usually reply within 1 day
-
Release notes show a broken link: `extract-changelog.sh` copies a reference but not its definitionOpenbug good first issue
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
Maintainers usually reply within 1 day
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 67/100
Maintainers usually reply within 1 day
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Maintainers usually reply within 1 day
All issues in vyncint/termlens
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
quarto-dev/q2#1005 ·
Maintainers usually reply within 1 day
-
[Request]: streamtopOpenpackage-request
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
ScoopInstaller/Extras#19205 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
storytold/craft-libs#477 ·
Maintainers usually reply within 1 day
-
security
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
Waschndolos/open-clubmanager#185 ·
Maintainers usually reply within 1 day
-
r-bug
Difficulty 1/5 Under an hour Newbie friendliness 88/100
servo/rust-smallvec#844 ·
Maintainers usually reply within 1 day