Use command to execute sed
#169
Conversation
|
Some other notes:
The motivation for this change is to avoid conflicts with (incompatible) |
We want our execution environment to be a predictable as possible. Similar to how we use `builtin` to ensure we're running the shell's builtin function (and not a redefinition), use `command` to ensure we're running `sed` and not a shell function or alias.
There was a problem hiding this comment.
- It would be nice to remove this
sedcall entirely, but it looks like it might be difficult to re-implement this in "native" bash.
Actually. you could simply do
eval "local trap_argv=(${__bp_trap_string:-})"
prior_trap=${trap_argv[2]}and it's more accurate. The current version in the master branch is broken when the trap string contains '. See this:
$ (trap "echo 'hello'" DEBUG; trap -p DEBUG)
hello
trap -- 'echo '\''hello'\''' DEBUG| @@ -300,7 +300,7 @@ __bp_install() { | |||
| local prior_trap | |||
| # we can't easily do this with variable expansion. Leaving as sed command. | |||
| # shellcheck disable=SC2001 | |||
| prior_trap=$(sed "s/[^']*'\(.*\)'[^']*/\1/" <<<"${__bp_trap_string:-}") | |||
| prior_trap=$(builtin command sed "s/[^']*'\(.*\)'[^']*/\1/" <<<"${__bp_trap_string:-}") | |||
There was a problem hiding this comment.
FWIW, we have been simply using command in bash-completion and oh-my-bash, though I know kitty shell integration prefixes builtin to everything where applicable.
There was a problem hiding this comment.
Yes, I made that as a last minute change given that I referenced builtin in my commit message. I think it's unlikely someone would attempt to redefine command, but using builtin command here does make this the most explicit.
There was a problem hiding this comment.
Yeah, either works for me, but then the next question would be whether we should prefix builtin to everything like builtin local, builtin return, builtin unset, builtin set, builtin shopt, etc.
That is much nicer! Will you create a new pull request using that approach? |
|
You can modify this PR. I don't care about the credit about it. |
I created #170 so the maintainers can compare the two approaches. |
Thanks! |
We want our execution environment to be a predictable as possible. Similar to how we use
builtinto ensure we're running the shell's builtin function (and not a redefinition), usecommandto ensure we're runningsedand not a shell function or alias.