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

fix argument type #5695

Merged
merged 7 commits into from
Jun 6, 2022
Merged

fix argument type #5695

merged 7 commits into from
Jun 6, 2022

Conversation

WindSoilder
Copy link
Collaborator

@WindSoilder WindSoilder commented Jun 2, 2022

Description

Fixes: #5056

Contains two part:

  1. while parsing input args, if we get list, parse it to Value::List rather than Value::String.
  2. Inside run_external, convert from Value::List to String Vec<Spanned<String>> to pass right arguments to external commands

Tests

Make sure you've run and fixed any issues with these commands:

  • cargo fmt --all -- --check to check standard code formatting (cargo fmt --all applies these changes)
  • cargo clippy --workspace --features=extra -- -D warnings -D clippy::unwrap_used -A clippy::needless_collect to check that you're using the standard code style
  • cargo test --workspace --features=extra to check that all the tests pass

@WindSoilder WindSoilder marked this pull request as draft June 2, 2022 06:48
@WindSoilder
Copy link
Collaborator Author

Hmm... closing first until I get better solution

@WindSoilder WindSoilder closed this Jun 2, 2022
@WindSoilder WindSoilder reopened this Jun 2, 2022
@WindSoilder WindSoilder marked this pull request as ready for review June 2, 2022 08:32
@kubouch
Copy link
Contributor

kubouch commented Jun 2, 2022

You need to be able to run some-external ["--some" "--arg"] as some-external --some --arg instead of some-external "--some --arg". In the second case, the external would interpret "--some --arg" as one argument instead of two arguments and would fail.

@WindSoilder
Copy link
Collaborator Author

WindSoilder commented Jun 2, 2022

Thanks for your comment, but that would make the following code in can't be run as expect:

nu -c [seq 1 2]

They seems to be conflict requirements -.-

Another solution maybe making nu as inner command ?

@kubouch
Copy link
Contributor

kubouch commented Jun 2, 2022

Yeah, that's expected. The nu -c supports string as an argument so you need to str collect it first. See my reply here: #5056 (comment)

@@ -294,7 +294,7 @@ pub fn parse_external_call(
let (arg, err) = parse_dollar_expr(working_set, *span, expand_aliases_denylist);
error = error.or(err);
args.push(arg);
} else if contents.starts_with(b"(") {
} else if contents.starts_with(b"[") {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this might work (so you can pass nu -c [ 'a' '-b' '--c' ], for example), but intstead of parse_full_cell_path(), I'd use parse_list_expression().

I'm not sure why this conditional was there in the first place since it's already checked above. Maybe @jntrnr knows?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you :-) parse_list_expression is explicit and better.

I'm not sure why this conditional was there in the first place since it's already checked above.

+1 for the not sure...

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the parens were originally so that you can do stuff like:

./external ("foo" + "bar.txt")

I think we still want to support this. If we bring in support for the string arrays, that should probably be a separate thing.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jntrnr Isn't the subexpression checked on the line 293 though?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hmmm, that 293 line looks odd. Are we really checking for ( as the start and then calling parse_dollar_expr? Does this cause any bugs in the current system?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

parse_dollar_expr goes to parse_full_cell_path which checks for (. So to me it seems this line is a duplicate.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if parse_dollar_expr just needs to be called something different now if it's doing more than parsing dollar expressions 😅

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, it doesn't seem very accurate anymore :-D. But I guess we can maybe rename it and leave the [ check for the list parsing?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm... should I change to something like this to make the logic more explicit?

if contents.starts_with(b"$") {
    let (arg, err) = parse_dollar_expr(working_set, *span, expand_aliases_denylist);
    error = error.or(err);
    args.push(arg);
} else if contents.starts_with(b"(") {
     let (arg, err) =
         parse_full_cell_path(working_set, None, *span, expand_aliases_denylist);
     error = error.or(err);
     args.push(arg);
 }

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you look at the parse_dollar_expr code it's actually parsing more than a dollar expression, so the original condition should be preserved. It's just a matter of adding for [...].

@kubouch
Copy link
Contributor

kubouch commented Jun 6, 2022

@WindSoilder I added some comments: I'd restore the original condition for parse_dollar_expr, then try to remove the if contents.starts_with(b"(") check for calling parse_full_cell_path and see if it breaks anything (seems like it shouldn't).

Could you also please add some tests covering this? We should test calling nu ([ '-c' 'version' ]) and nu ['-c' 'version'] and make sure both work. You can use the nu-test-support crate for this: See the nushell/tests directory for examples.

@WindSoilder
Copy link
Collaborator Author

@kubouch Thanks, I've added new tests for them and revert my recent change on parser.

@kubouch
Copy link
Contributor

kubouch commented Jun 6, 2022

Nice! Ok, let's give it a try. Thanks again for the PR!

@kubouch kubouch merged commit 75b2d26 into nushell:main Jun 6, 2022
@WindSoilder WindSoilder deleted the fix_calling branch June 6, 2022 10:29
fennewald pushed a commit to fennewald/nushell that referenced this pull request Jun 27, 2022
* fix argument type

* while run external, convert list argument to str

* fix argument converting logic

* using parse_list_expression instead of parse_full_cell_path

* make parsing logic more explicit

* revert changes

* add tests
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.

nu ['-c' 'version'] doesn't work as expected
3 participants