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

env: implement -S/--split-string #5710

Closed
sylvestre opened this issue Dec 24, 2023 · 6 comments
Closed

env: implement -S/--split-string #5710

sylvestre opened this issue Dec 24, 2023 · 6 comments
Labels

Comments

@sylvestre
Copy link
Contributor

The GNU doc says:

       -S, --split-string=S
              process and split S into separate arguments; used to pass multiple arguments on shebang lines

The code:
https://github.com/uutils/coreutils/blob/main/src/uu/env/src/env.rs

Tested in GNU with tests/env/env-S.pl

@sylvestre sylvestre changed the title env: implement -S env: implement -S/--split-string Dec 24, 2023
@cre4ture
Copy link
Contributor

I can reproduce and run the gnu test. I'll start with working on a fix now.

@cre4ture
Copy link
Contributor

I ran into a challenge and I could make use of some ideas.
I need to split the string provided the same way as a shell would do it.
This is trivial with strings like this part1 part2 part3, but it gets more tricky with having quotes and escaped quotes:
part1 "part2 with spaces" "part3 with a \"name\" that is escaped"

Is there something like this already available in uutils or a external crate?

@cre4ture
Copy link
Contributor

I'll try to use crate quoted-string = "0.6.1"

@cre4ture
Copy link
Contributor

cre4ture commented Dec 29, 2023

I tried multiple different crates that claim parsing shell like syntax, but none of them supports all the corner cases from the gnu test suite. This is a really challenging task. I briefly checked the gnu implementation. They are really implementing their own custom parser for this. I would really like to avoid this. But maybe we don't get around this if we want the test suite pass 100%. What do you think? Is it worth to implement some own parser? Or should we start to improve an existing, but external crate?

@tertsdiepraam
Copy link
Member

The format seems very specific based on the docs here: https://www.gnu.org/software/coreutils/manual/html_node/env-invocation.html#g_t_002dS_002f_002d_002dsplit_002dstring-syntax

I think it should unfortunately be a custom parser, because other crates probably aren't interested in this functionality and we need 100% compatibility. Maybe we could use nom for this. I'd suggest to implement the simple cases first. So start with having just quotes, for example, and add other functionality in later PRs.

Also, I have to ask you not to look at the GNU source code for licensing reasons. We need to implement this based on the test suite and the documentation alone.

@BenWiederhake
Copy link
Collaborator

I think this was implemented by #5801.

Fun fact: If you write in a PR on a separate line "Fixes #5710", then GitHub automatically closes the related issue. That really comes in handy :)
Example: #6020

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Status: Done
Development

No branches or pull requests

4 participants