Use command to execute sed

[jparise]

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.

[jparise]

Some other notes:

• We could also use the \sed syntax if that's preferred.
• It would be nice to remove this sed call entirely, but it looks like it might be difficult to re-implement this in "native" bash.

The motivation for this change is to avoid conflicts with (incompatible) sed aliases: ghostty-org/ghostty#4991

[akinomyoga]

• It would be nice to remove this sed call 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

[akinomyoga]

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.

[jparise]

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.

[akinomyoga]

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.

[jparise]

• It would be nice to remove this sed call 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]}

That is much nicer! Will you create a new pull request using that approach?

[akinomyoga]

You can modify this PR. I don't care about the credit about it.

[jparise]

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.

[akinomyoga]

I created #170 so the maintainers can compare the two approaches.

Thanks!

[akinomyoga]

I think #170 is better.

[akinomyoga]

@rcaloras Thanks for checking and merging PRs! Now that #170 is merged, this PR (which implements an alternative approach to #170) can be closed.