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

Shell escape process arguments that are printed out #1673

Merged
merged 6 commits into from
Jul 1, 2015

Conversation

bluss
Copy link
Member

@bluss bluss commented Jun 2, 2015

Shell escape process arguments that are printed out

cargo build --verbose does output some command lines that cannot be
simply copy and pasted into the shell again. The problem is the
arguments which are output exactly like this: --feature="foo"

When pasted back into the shell, the shell will parse and remove the
double quotes. To counteract this, escape special shell characters when
printing commandlines. Cargo will print --feature="foo" instead, which
can be pasted back into the shell.

root added 4 commits June 2, 2015 15:21
cargo build --verbose does output some command lines that cannot be
simply copy and pasted into the shell again. The problem is the
arguments which are output exactly like this: --feature="foo"

When pasted back into the shell, the shell will parse and remove the
double quotes. To counteract this, escape special shell characters when
printing commandlines. Cargo will print --feature=\"foo\" instead, which
can be pasted back into the shell.
With great help from @retep998
@rust-highfive
Copy link

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @huonw (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. The way Github handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

@bluss
Copy link
Member Author

bluss commented Jun 2, 2015

Successor of #1572. I think Windows support is still WIP.

Ok, it was explained that no detection is needed. Just escape " and spaces on windows by quoting the arguments, also replace all backslashes with slashes.

Unfortunately the old fail log is gone and I can't find where it failed on windows the last time, but there must be some test that needs to be updated.

r#""--features=\"default\"""#);
assert_eq!(shell_escape(r#"\path\to\my documents\"#.into()),
r#""/path/to/my documents/""#);
}
Copy link
Member Author

Choose a reason for hiding this comment

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

(See above) @retep998 is this the right way to escape? It adds double quotes if it finds double quotes or spaces.

Copy link
Member

Choose a reason for hiding this comment

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

If it has spaces in it then you add double quotes around it. If it has double quotes in it, then you add backslashes. You do not need to add double quotes around it if it has double quotes in it.

Copy link
Member Author

Choose a reason for hiding this comment

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

ah, ok, I'll fix that.

@emberian
Copy link
Member

emberian commented Jun 2, 2015

@bors: try

@alexcrichton
Copy link
Member

@bors: r+ f8e0231

Thanks!

@bors
Copy link
Collaborator

bors commented Jun 2, 2015

⌛ Testing commit f8e0231 with merge 20b67d4...

@bors
Copy link
Collaborator

bors commented Jun 2, 2015

💔 Test failed - cargo-win-gnu-32

@alexcrichton
Copy link
Member

I'd personally recommend not using #[cfg] here and instead using if cfg!(windows) as it'll allow typechecking on all platforms.

Also in theory if you're using a MSYS shell on Windows you should use the same escaping as the unix shell, but that can always be implemented later.

@bluss
Copy link
Member Author

bluss commented Jun 2, 2015

Oh that's a mistake. The intention was for both windows and other to both compile and test always -- which they do on linux.

pub use self::windows::shell_escape;


#[cfg(any(test, target_os = "windows"))]
Copy link
Member

Choose a reason for hiding this comment

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

er actually I was thinking that this would remove the #[cfg] attributes in this module entirely, and instead have a top-level function that used if cfg!(...)

Copy link
Member Author

Choose a reason for hiding this comment

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

I would do this change, it makes sense, but the way I had it now, I tested both versions on any platform.

@bluss
Copy link
Member Author

bluss commented Jun 24, 2015

I'm sorry, I can't really work on something that I can't run & test (i.e. Windows support).

@bluss
Copy link
Member Author

bluss commented Jun 24, 2015

It would be better to merge this with single platform support only, and then have another contributor pick up the windows support -- in a PR that they can develop & test on that platform.

@alexcrichton
Copy link
Member

The Windows bots are failing because backslashes are being translated to forward slashes, so tests need to be updated, but I'm also not 100% convinced that we can do this kind of translation as it's changing the input. Do you have a link to the documentation for Windows on how the string may be escaped?

@bluss
Copy link
Member Author

bluss commented Jun 30, 2015

Thanks, I didn't use any docs, I just talked with @retep998 :)

bors added a commit that referenced this pull request Jul 1, 2015
@bors bors merged commit 877a85e into rust-lang:master Jul 1, 2015
@bluss bluss deleted the shell-escape branch July 1, 2015 08:07
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.

7 participants