Skip to content

[sed] Fix bin wrappers when sed is installed with devbox #1566

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

Merged
merged 1 commit into from
Oct 17, 2023

Conversation

mikeland73
Copy link
Contributor

@mikeland73 mikeland73 commented Oct 17, 2023

Summary

TSIA

How was it tested?

Using this config: https://discord.com/channels/903306922852245526/1009933892385517619/1163763578399105064

Pre-change, could not shell in, got bash nesting error.
Post-change, could shell in.

@Lagoja
Copy link
Contributor

Lagoja commented Oct 17, 2023

Interesting, so this issue specifically happens if the user installs sed via one of the coreutils packages?

@mikeland73
Copy link
Contributor Author

Interesting, so this issue specifically happens if the user installs sed via one of the coreutils packages?

yep, it creates infinite recursion. coreutils also installs echo but that doesn't seem to lead to the infinite loop (I guess bash defaults to the built-in). I could pre-emptively add the same logic for echo but it doesn't seem to be an issue.

@mikeland73 mikeland73 merged commit c694277 into main Oct 17, 2023
@mikeland73 mikeland73 deleted the landau/fix-sed branch October 17, 2023 19:10
@@ -48,6 +48,7 @@ func CreateWrappers(ctx context.Context, args CreateWrappersArgs) error {
_ = os.MkdirAll(destPath, 0o755)

bashPath := cmdutil.GetPathOrDefault("bash", "/bin/bash")
sedPath := cmdutil.GetPathOrDefault("sed", "sed")
Copy link
Collaborator

Choose a reason for hiding this comment

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

Won't the default value trigger the bug again? Should the default be /usr/bin/sed to mirror /bin/bash above?

Copy link
Contributor Author

@mikeland73 mikeland73 Oct 18, 2023

Choose a reason for hiding this comment

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

Yeah if sed is not in path this will trigger same issue. Though if sed is not in path the wrapper would have failed anyway. sed is POSIX so I kinda assume it exists. I can fix it, but

There's an additional problem that affects sed and bash. If you are using global and a project devbox and both install sed and/or bash, you could end up cycling between both wrappers recursivelly. For example:

  • Add coreutils to project (bin wrappers use /usr/bin/sed)
  • Add coreutils to global while shelled in to project (bin wrappers use sed in project)
  • Make some change to project, now sed in bin wrapper points to global sed
  • Cycle

Another edge case:

  • if 2 devbox processes are creating wrappers at the same time, theres a chance the second one will point to the bin wrapper incorrectly.

These are pretty edge cases, but would suck. I think a better solution is to just special case sed and bash and never bin wrap them. Thoughts?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Follow up #1571

Copy link
Collaborator

Choose a reason for hiding this comment

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

Ah yeah, nested environments would throw everything off. I commented in the other PR with some ideas.

mikeland73 added a commit that referenced this pull request Oct 18, 2023
## Summary

This feels like the safest solution to
#1566 (comment)

It also avoids creating bin wrappers for `bash` and `sed` which reduces
risk and improves performance.

## How was it tested?

Used setup from #1566

```
devbox shell
devbox add bash
hash -r
which bash # ensure I get profile bash instead of wrapped bash
```
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

4 participants