-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
fix argument type #5695
Conversation
Hmm... closing first until I get better solution |
You need to be able to run |
Thanks for your comment, but that would make the following code in can't be run as expect:
They seems to be conflict requirements -.- Another solution maybe making |
Yeah, that's expected. The |
@@ -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"[") { |
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 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?
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.
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...
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 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.
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.
@jntrnr Isn't the subexpression checked on the line 293 though?
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.
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?
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.
parse_dollar_expr
goes to parse_full_cell_path
which checks for (
. So to me it seems this line is a duplicate.
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 wonder if parse_dollar_expr
just needs to be called something different now if it's doing more than parsing dollar expressions 😅
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.
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?
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.
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);
}
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.
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 [...]
.
@WindSoilder I added some comments: I'd restore the original condition for Could you also please add some tests covering this? We should test calling |
@kubouch Thanks, I've added new tests for them and revert my recent change on parser. |
Nice! Ok, let's give it a try. Thanks again for the PR! |
* 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
Description
Fixes: #5056
Contains two part:
list
, parse it toValue::List
rather thanValue::String
.run_external
, convert fromValue::List
toStringVec<Spanned<String>>
to pass right arguments to external commandsTests
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 stylecargo test --workspace --features=extra
to check that all the tests pass