Merged
Conversation
The behavior of the `echo` command and its handling of escape sequences, such as `\n`, can exhibit variability across different implementations of shells and utilities. This variability was evident during my experience while executing the `install.sh` script on a newly installed Fedora system: ```bash [xander@fedora ~]$ curl https://rtx.pub/install.sh | sh % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 4302 100 4302 0 0 78350 0 --:--:-- --:--:-- --:--:-- 79666 rtx: installing rtx... rtx: installed successfully to /home/xander/.local/share/rtx/bin/rtx rtx: run the following to activate rtx in your shell: echo "eval \"\$(/home/xander/.local/share/rtx/bin/rtx activate bash)\"" >> ~/.bashrc\n # <--newline rtx: this must be run in order to use rtx in the terminal rtx: run `rtx doctor` to verify this is setup correctly ``` Furthermore, a direct copy-paste of the command could potentially lead to unintended consequences. For instance, when executed in a bash shell, the command may inadvertently remove the trailing backslash: ```bash [xander@fedora ~]$ echo "eval \"\$(/home/xander/.local/share/rtx/bin/rtx activate bash)\"" >> ~/.bashrc\n [xander@fedora ~]$ cat .bashrcn # note the `n` at the end eval "$(/home/xander/.local/share/rtx/bin/rtx activate bash)" [xander@fedora ~] ``` Podman testing showed consistent `echo` behavior with bash across distributions, except for Debian and Ubuntu (using dash) which interpret escape sequences by default. Thus, replacing the newlines with empty `info` calls appears to be the most portable solution.
Codecov ReportPatch coverage has no change and project coverage change:
Additional details and impacted files@@ Coverage Diff @@
## main #842 +/- ##
==========================================
+ Coverage 81.27% 87.60% +6.33%
==========================================
Files 132 132
Lines 11533 11533
==========================================
+ Hits 9373 10104 +731
+ Misses 2160 1429 -731 ☔ View full report in Codecov by Sentry. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The behavior of the
echocommand and its handling of escape sequences, such as\n, can exhibit variability across different implementations of shells and utilities. This variability was evident during my experience while executing theinstall.shscript on a newly installed Fedora system:Furthermore, a direct copy-paste of the command could potentially lead to unintended consequences. For instance, when executed in a bash shell, the command may inadvertently remove the trailing backslash:
Podman testing showed consistent
echobehavior with bash across distributions, except for Debian and Ubuntu (using dash) which interpret escape sequences by default. Thus, replacing the newlines with emptyinfocalls appears to be the most portable solution.