-
Notifications
You must be signed in to change notification settings - Fork 180
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
Improve misc implementation in Bash #430
Conversation
Are there any issues with bash 3 vs 4 vs 5 with these changes? I know we've had issues in the past on older systems (mostly Macs I think). |
Thanks for your review. These should work in Bash 3.1+. To use the array However, Bash 3.0 would fail to parse |
I'd suggest including a check for the Bash version (>= 3.1 or >= 3.0) at the beginning of |
Yes, thank you. Maybe we just warn if it's older than 3.1? If that's on Mac and Linux by default than I don't think we need to support less than 3.1. |
8ad6576
to
70efe35
Compare
rebased |
I added 9bf6891 and 03ef43f for the Bash version check. I finally decided to include the support for Bash 3.0. To perform the Bash version check properly, we anyway need to allow lower versions of Bash to parse the script. Then, Bash 3.0 actually works under such a modification. Details--Because of the nature of the script that is supposed to be evaluated by |
The command "which" is a non-POSIX external command, and technically, its existence in the system is not ensured. We here use Bash's built-in command "type", which is the most reliable. We prefix "builtin" to "type" because some users overwrite "type" with a shell function or an alias to mimic Windows' "type" command. The use of the which command was first removed in Ref. [1]. However, this was reverted after the issue in Ref. [2]. As far as a relative path is not contained in PATH, the problem reported in Ref. [2] does not seem to be reproducible in all the versions from Bash 3.0 to 5.2 and in the devel branch of Bash. However, when the path "./bin" is included in PATH, the "command -v" produces the relative path "./bin/mcfly" as reported. This seems to have been solved by using the "which command in the reporter's environment, but the behavior of the "which" command may depend on the implementation. We should explicitly resolve the relative path if the obtained MCFLY_PATH is relative. References: [1] cantino#216 [2] cantino#292 [3] cantino#430 (comment)
855c101
to
53f3314
Compare
The command "which" is a non-POSIX external command, and technically, its existence in the system is not ensured. We here use Bash's built-in command "type", which is the most reliable. We prefix "builtin" to "type" because some users overwrite "type" with a shell function or an alias to mimic Windows' "type" command. The use of the which command was first removed in Ref. [1]. However, this was reverted after the issue in Ref. [2]. As far as a relative path is not contained in PATH, the problem reported in Ref. [2] does not seem to be reproducible in all the versions from Bash 3.0 to 5.2 and in the devel branch of Bash. However, when the path "./bin" is included in PATH, the "command -v" produces the relative path "./bin/mcfly" as reported. This seems to have been solved by using the "which command in the reporter's environment, but the behavior of the "which" command may depend on the implementation. We should explicitly resolve the relative path if the obtained MCFLY_PATH is relative. References: [1] cantino#216 [2] cantino#292 [3] cantino#430 (comment)
This is to avoid later error messages in the case MCFLY_PATH contained an invalid/outdated path before the initialization by mcfly.bash.
We perform this in a shell function to temporarily set IFS.
53f3314
to
cc37257
Compare
The command "which" is a non-POSIX external command, and technically, its existence in the system is not ensured. We here use Bash's built-in command "type", which is the most reliable. We prefix "builtin" to "type" because some users overwrite "type" with a shell function or an alias to mimic Windows' "type" command. The use of the which command was first removed in Ref. [1]. However, this was reverted after the issue in Ref. [2]. As far as a relative path is not contained in PATH, the problem reported in Ref. [2] does not seem to be reproducible in all the versions from Bash 3.0 to 5.2 and in the devel branch of Bash. However, when the path "./bin" is included in PATH, the "command -v" produces the relative path "./bin/mcfly" as reported. This seems to have been solved by using the "which command in the reporter's environment, but the behavior of the "which" command may depend on the implementation. We should explicitly resolve the relative path if the obtained MCFLY_PATH is relative. References: [1] #216 [2] #292 [3] #430 (comment)
Thanks @akinomyoga! |
Thanks! |
This has introduced a bug. See #435 |
This conflicts with #429, but after either one is merged, I'll rebase the other to resolve the conflicts.