-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Throw error if unset argument starts with '=' for env command #6172
base: main
Are you sure you want to change the base?
Conversation
Hi again! I made a mistake and merged your other PR a bit too quickly, which is why the other maintainers had to do a force-push. Sorry ^^' I'd be happy to help you sort out this mess in case you get stuck with |
Thanks for your help I will try to fix it and if I fail I will certainly ask you on discord. |
Please rebase your work |
bd361f7
to
403da10
Compare
Thanks for your patience! Its ready to be reviewed now. |
Fix clippy error Fix formatting Simplify unset prefix handling Also include '=' in invalid_arg cargo fmt
please fix the lint |
I think all the lint tests have passed, haven't they? |
tests/by-util/test_env.rs
Outdated
@@ -7,6 +7,7 @@ | |||
#[cfg(target_os = "linux")] | |||
use crate::common::util::expected_result; | |||
use crate::common::util::TestScenario; | |||
#[rustfmt::skip] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm very surprised that this is necessary, and can't reproduce it. In fact, all CI so far always was green, so this is not a systemic issue. Also, removing the leading ::
would break the code, so any program that suggests just removing them without replacement is obviously wrong.
Which rustfmt version are you using, and how exactly do you invoke it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am doing cargo fmt --all
and when I run that it removes ::
in front of env this resulting in error.
$ rustfmt --version
rustfmt 1.7.0-stable ( )
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
please remove these skips :)
if needed, we will fix them into a different PR
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Huh, that is very weird.
$ cargo +stable fmt --version # I have the same version as you
rustfmt 1.7.0-stable (07dca48 2024-02-04)
$ cargo +stable fmt --all --check # It does not report anything
$ cargo +stable fmt --all # And running it in the same manner …
$ git diff # … does not cause any file changes.
$
If the formatting issues cause pre-commit to fail, you can skip it completely via git commit --no-verify
. However, that's just a temporary solution.
Seems that it needs more work:
With GNU:
|
Ok thanks I will look into it. |
These are some other results with GNU that don't match:
|
I am converting this to a draft pr until I fix these. |
src/uu/env/src/env.rs
Outdated
// clap automatically removes '=' from the beginning of the argument, so we need to check for it | ||
for arg in &original_args { | ||
let arg = arg.to_string_lossy(); | ||
let prefix = "-u="; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wouldn't that break something like env echo gotcha -u=hello
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, it definitely wouldn't catch env -vu=hello
.
Suggestion: Instead of trying to parse the arguments again, is there a way to examine matches
to determine what the exact argument was that leads clap to believe something? This should be much more robust.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice catch, it really breaks it. Also, I have found some more cases where it breaks things. I am not sure of what approach I should do, because it looks like I am trying to shoehorn too much of if conditions to match the gnu behavior. Some help would be appreciated.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, it definitely wouldn't catch
env -vu=hello
.Suggestion: Instead of trying to parse the arguments again, is there a way to examine
matches
to determine what the exact argument was that leads clap to believe something? This should be much more robust.
I tried doing something with clap but it turns out that clap removes '=' before the argument by itself.
$ cargo run env -u=kQ4dALb1 A=0d CZj=lYr
This is what matches print:
matches: ArgMatches { valid_args: ["ignore-environment", "chdir", "null", "file", "unset", "debug", "split-string", "vars", "help", "version"], valid_subcommands: [], args: FlatMap { keys: ["unset", "vars", "ignore-environment", "null", "debug"], values: [MatchedArg { source: Some(CommandLine), indices: [2], type_id: Some(std::ffi::os_str::OsString), vals: [[AnyValue { inner: std::ffi::os_str::OsString }]], raw_vals: [["kQ4dALb1"]], ignore_case: false }, MatchedArg { source: Some(CommandLine), indices: [3, 4], type_id: Some(std::ffi::os_str::OsString), vals: [[AnyValue { inner: std::ffi::os_str::OsString }], [AnyValue { inner: std::ffi::os_str::OsString }]], raw_vals: [["A=0d"], ["CZj=lYr"]], ignore_case: false }, MatchedArg { source: Some(DefaultValue), indices: [5], type_id: Some(bool), vals: [[AnyValue { inner: bool }]], raw_vals: [["false"]], ignore_case: false }, MatchedArg { source: Some(DefaultValue), indices: [6], type_id: Some(bool), vals: [[AnyValue { inner: bool }]], raw_vals: [["false"]], ignore_case: false }, MatchedArg { source: Some(DefaultValue), indices: [7], type_id: Some(bool), vals: [[AnyValue { inner: bool }]], raw_vals: [["false"]], ignore_case: false }] }, subcommand: None }
Some more deviations from gnu are
After some testing I have found that gnu works if there is -i or '-' before or after '-u=adsfas'. |
GNU testsuite comparison:
|
is it ready to be reviewed? Thanks |
No, sorry it isn't ready for review. This pr wont work because of so many weird behavior by gnu as mentioned in my previous comments. |
Sure sounds good :) |
I think I have added enough tests. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for collecting and implementing the test cases! Currently, CI fails because the tests are run (and fail), therefore this cannot be merged. Also, I have the impression that some of these commands should behave differently, are you sure about the expected results? (See below)
#6165
#6166
Output
Before:
After:
Tests:
Before:
After: