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

Escape tilde more gracefully #16560

Closed
wants to merge 2 commits into from
Closed

Conversation

comius
Copy link
Contributor

@comius comius commented Oct 26, 2022

Tilde needs to be escaped only when it's the first character after the white space. Otherwise, we can keep the string unescaped.

This supports bzlmod better, because tilde is used in the directory names.

Users often already escape location function, for example SJ="$(location @bazel_tools//tools/jdk:singlejar)"; $SJ. Without the change this becomes 'external/repo~name/singlejar' and the script fails (no file found).

Location function shouldn't be escaped. But without this change we risk a lot of users will need to fix their scripts.

Tilde needs to be escaped only when it's the first character after the white space. Otherwise, we can keep the string unescaped.

This supports bzlmod better, because tilde is used in the directory names.

Users often already escape location function, for example `SJ="$(location @bazel_tools//tools/jdk:singlejar)"; $SJ`. Without the change this becomes ``"'external/repo~name/singlejar'"` and the script fails (no file found).

Location function shouldn't be escaped. But without this change we risk a lot of users will need to fix their scripts.
@comius
Copy link
Contributor Author

comius commented Oct 26, 2022

cc @Wyverald, @fmeum

Copy link
Collaborator

@fmeum fmeum left a comment

Choose a reason for hiding this comment

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

Thanks for catching this!

@@ -41,6 +41,8 @@ public void shellEscape() throws Exception {
assertThat(escapeString("\\'foo\\'")).isEqualTo("'\\'\\''foo\\'\\'''");
assertThat(escapeString("${filename%.c}.o")).isEqualTo("'${filename%.c}.o'");
assertThat(escapeString("<html!>")).isEqualTo("'<html!>'");
assertThat(escapeString("~not_home")).isEqualTo("'~not_home'");
assertThat(escapeString("external/protobuf~3.19.6/src/google")).isEqualTo("external/protobuf~3.19.6/src/google");
Copy link
Collaborator

Choose a reason for hiding this comment

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

Just to be safe, could you add a test case for external/~install_dev_dependencies~foo/pkg? This is a path that Bzlmod can generate and it's slightly more special as the tilde is the first character of a path segment.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I added a unit tests, but this doesn't tell us much. I tested manually:

~$ mkdir tmp
~$ mkdir tmp/~tilde
~$ cd tmp/~tilde/
~/tmp/~tilde$ cd ..
~/tmp$ cd ~tilde
bash: cd: /usr/local/google/home/tilde: No such file or directory
i~/tmp$ cd '~tilde'
~/tmp/~tilde$

Copy link
Collaborator

@fmeum fmeum Oct 26, 2022

Choose a reason for hiding this comment

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

Luckily, I don't think that Bazel will generate paths where the first segment starts with a tilde in any situation. At the moment that is, I think that this may change with --experimental_sibling_repository_layout, where paths can start with repository names. These paths would not work without escaping.

@Wyverald Do you see other cases where this could be problematic?

Edit: This actually means that the output of $(rlocationpath //label) from #16428 may end up being escaped.

@Wyverald Could we ensure that repositories generated by the main module are prefixed with _main~ rather than just ~? That would probably solve this problem for good, even with --experimental_sibling_repository_layout.

Copy link
Member

Choose a reason for hiding this comment

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

Bash seems to consider paths starting with '~' special: https://www.gnu.org/software/bash/manual/html_node/Tilde-Expansion.html

Copy link
Collaborator

Choose a reason for hiding this comment

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

#16564 should ensure that paths emitted by Bazel never start with ~.

@fmeum
Copy link
Collaborator

fmeum commented Oct 26, 2022

@bazel-io flag

@bazel-io bazel-io added the potential release blocker Flagged by community members using "@bazel-io flag". Should be added to a release blocker milestone label Oct 26, 2022
@sgowroji sgowroji added team-ExternalDeps External dependency handling, remote repositiories, WORKSPACE file. awaiting-review PR is awaiting review from an assigned reviewer labels Oct 26, 2022
@Wyverald Wyverald added awaiting-PR-merge PR has been approved by a reviewer and is ready to be merge internally and removed awaiting-review PR is awaiting review from an assigned reviewer labels Oct 26, 2022
@fmeum
Copy link
Collaborator

fmeum commented Oct 26, 2022

@bazel-io flag

fmeum pushed a commit to fmeum/bazel that referenced this pull request Oct 27, 2022
Tilde needs to be escaped only when it's the first character after the white space. Otherwise, we can keep the string unescaped.

This supports bzlmod better, because tilde is used in the directory names.

Users often already escape location function, for example `SJ="$(location @bazel_tools//tools/jdk:singlejar)"; $SJ`. Without the change this becomes `'external/repo~name/singlejar'` and the script fails (no file found).

Location function shouldn't be escaped. But without this change we risk a lot of users will need to fix their scripts.

Closes bazelbuild#16560.

PiperOrigin-RevId: 484226256
Change-Id: I6b71f89a649f8494b76a4446b8f6384421eb89d1
@sgowroji sgowroji removed the awaiting-PR-merge PR has been approved by a reviewer and is ready to be merge internally label Oct 27, 2022
copybara-service bot pushed a commit that referenced this pull request Oct 27, 2022
By ensuring that repository names do not start with `~`, runfiles paths are certain not to begin with tildes, which means that they don't need to be shell escaped.

Prevents #16560 (comment)

Closes #16564.

PiperOrigin-RevId: 484232215
Change-Id: Ie70940aa709f6c7a886564189a3579780731dca6
fmeum added a commit to fmeum/bazel that referenced this pull request Oct 27, 2022
By ensuring that repository names do not start with `~`, runfiles paths are certain not to begin with tildes, which means that they don't need to be shell escaped.

Prevents bazelbuild#16560 (comment)

Closes bazelbuild#16564.

PiperOrigin-RevId: 484232215
Change-Id: Ie70940aa709f6c7a886564189a3579780731dca6
ShreeM01 pushed a commit that referenced this pull request Oct 27, 2022
By ensuring that repository names do not start with `~`, runfiles paths are certain not to begin with tildes, which means that they don't need to be shell escaped.

Prevents #16560 (comment)

Closes #16564.

PiperOrigin-RevId: 484232215
Change-Id: Ie70940aa709f6c7a886564189a3579780731dca6
ShreeM01 added a commit that referenced this pull request Oct 27, 2022
Tilde needs to be escaped only when it's the first character after the white space. Otherwise, we can keep the string unescaped.

This supports bzlmod better, because tilde is used in the directory names.

Users often already escape location function, for example `SJ="$(location @bazel_tools//tools/jdk:singlejar)"; $SJ`. Without the change this becomes `'external/repo~name/singlejar'` and the script fails (no file found).

Location function shouldn't be escaped. But without this change we risk a lot of users will need to fix their scripts.

Closes #16560.

PiperOrigin-RevId: 484226256
Change-Id: I6b71f89a649f8494b76a4446b8f6384421eb89d1

Co-authored-by: Ivo List <ilist@google.com>
Co-authored-by: kshyanashree <109167932+kshyanashree@users.noreply.github.com>
@Wyverald Wyverald removed the potential release blocker Flagged by community members using "@bazel-io flag". Should be added to a release blocker milestone label Dec 1, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
team-ExternalDeps External dependency handling, remote repositiories, WORKSPACE file.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants