Skip to content

Default to looking for tools on PATH, rather than requiring them to be in /usr/bin - #463

Merged
pehrsoderman merged 4 commits into
Kattis:masterfrom
gkreitz:103_non_absolute_path_to_language_tools
Aug 20, 2026
Merged

Default to looking for tools on PATH, rather than requiring them to be in /usr/bin#463
pehrsoderman merged 4 commits into
Kattis:masterfrom
gkreitz:103_non_absolute_path_to_language_tools

Conversation

@gkreitz

@gkreitz gkreitz commented Aug 20, 2026

Copy link
Copy Markdown
Contributor

This PR allows one to configure a language where the path to the compiler or interpreter is not absolute (e.g., gcc rather then /usr/bin/gcc). Such paths will be resolved using $PATH. This PR also changes the default config to make use of this, so now it will compile C programs using the first gcc in $PATH, rather than /usr/bin/gcc.

Additionally, fixes an old omission. If the runtime for a language (e.g., java) is missing, earlier we'd attempt to execute it and give a misleading run-time error. Now, we'll flag that as a compile error, the same way we do if the compiler is missing.

Fixes #103

@gkreitz

gkreitz commented Aug 20, 2026

Copy link
Copy Markdown
Contributor Author

Codefactor checks are silly (hard coded paths to /tmp in a unit tests are not a security vulnerability. I'll see if I can coax codefactor into being less silly (but iirc, it was a bit annoying to get it to pick up bandit rules in a good way).

@gkreitz
gkreitz force-pushed the 103_non_absolute_path_to_language_tools branch from 04382b9 to 579363e Compare August 20, 2026 09:47
@pehrsoderman
pehrsoderman merged commit fb85f50 into Kattis:master Aug 20, 2026
7 checks passed
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.

languages.yaml should accept compilers in path and not hardwire absolute paths

2 participants