Strings are not passed as they are to externals

[elferherrera]

Describe the bug

The next command errors because the string after the filter is not passed as it is

gcloud dataproc jobs list --region europe-west1 --limit=50 --filter="labels.table_name=vagabond_tranches" --sort-by="statusHistory[0].stateStartTime"

The error received from the external is this one

ERROR: (gcloud.dataproc.jobs.list) INVALID_ARGUMENT: Could not parse the filter: Unexpected property ''. Expected one of [labels, clusterName, placement.clusterName, status.state, operationType]

How to reproduce

run external command that requires an argument with string

Expected behavior

The string is passed correctly to the argument

Screenshots

No response

Configuration

No response

Additional context

No response

[elferherrera]

It seems this is not related to nushell but to rust itself

This issue describes it and there is a nightly feature waiting for approval.

I'm closing this issue but leaving this for future reference

[sophiajt]

Let's leave this open and tag it upstream. We may have to work with the Rust teams to help finish it.

[sophiajt]

@elferherrera - the issue you linked to is marked Windows-specific. Seems like it would fix the issue you saw on Windows, but you originally saw it on macOS too right?

[elferherrera]

I see the issue with externals in MacOS and Windows operating system. I linked to that issue for reference with scaped quotes

[JCallicoat]

I just found in a another issue that nu seems to be passing the double quotes literally to external commands that have flags with an = (#4609 (comment)) which seems like it could be related. Could you try your command with spaces on those flags instead of equals, i.e., --filter "labels.table_name=vagabond_tranches" --sort-by "statusHistory[0].stateStartTime" and see if it works?

[JCallicoat]

Simple reproducer to show the quotes being passed through to the command:

// foo.c
#include <stdio.h>
int main(int argc, char **argv) {
    for (int i=1; i < argc; i++) {
        puts(argv[i]);
    }
}

gcc -o foo foo.c

./foo --filter="labels.table_name=vagabond_tranches"
--filter="labels.table_name=vagabond_tranches"

Compared to zsh:

./foo --filter="labels.table_name=vagabond_tranches"
--filter=labels.table_name=vagabond_tranches

[elferherrera]

@JCallicoat I can confirm that by adding a space the external command works

[elferherrera]

@jntrnr @fdncred Should we add a config flag that removes quotes from arguments to externals to behave like bash?

[fdncred]

Should we add a config flag that removes quotes from arguments to externals to behave like bash?

imo, passing arguments to externals should "just work". we continually have issues with it. I'd like to resolve it once and for all. I'm not sure what that resolution looks like though.

[elferherrera]

The thing is that bash and zsh does thing differently. Bash removes all quotes before passing it to the external, zsh does it sometimes

[fdncred]

I'm willing to try just about anything in order to quit having complaints about external parameters not working.

[elferherrera]

In that case I would suggest to go the bash route. It removes all quotes from the arguments to externals. For example, if I call this external like this in bash

arg_tester dataproc jobs list --region europe-west1 --limit=50 --filter="labels.table_name=vagabond_tranches && labels=something" --sort-by="statusHistory[0].stateStartTime"

it is received by the external like this

["./target/debug/arg_tester", "dataproc", "jobs", "list", "--region", "europe-west1", "--limit=50", "--filter=labels.table_name=vagabond_tranches && labels=something", "--sort-by=statusHistory[0].stateStartTime"]

Notice that the quotes for --filter and --sort-by are removed after the equal sign

[fdncred]

Sounds good to me. I'm willing to try that and see how it goes.