Re-adjust PROMPT_COMMAND when PROMPT_COMMAND is modified elsewhere

[akinomyoga]

This is the fix for #140. The author of #140 seems to have fixed the issue by directly modifying the C source code of Midnight Commander mc, but we could work around the modified PROMPT_COMMAND at bash-preexec's side.

In this patch, when the PROMPT_COMMAND is modified by users or by another code (such as mc) to have commands outside __bp_precmd_invoke_cmd...__bp_interactive_mode, bash-preexec adjust PROMPT_COMMAND again so that every external command is enclosed within __bp_precmd_invoke_cmd and __bp_interactive_mode.

In this PR, other code adjustments are included as in the following list. I think these commits are closely related to each other, but if you think some of them should be discussed in a separate PR, please let me know.

• In commit fe5aedb, I refactored __bp_sanitize_string to include some processing that has been done outside of it. (such as that of Try to better handle external modification to $PROMPT_COMMAND #128), to use the function in implementing the string manipulation of PROMPT_COMMAND.
• Commit 299080e is a workaround for shopt -u extglob. The problem is explained in the code comment.
• Commit c85de1b is the main part of this patch, which re-adjusts PROMPT_COMMAND.
• Commit 9c669e6 works around the situation that multiple pairs of our hooks are installed. We try to remove the existing hooks in the re-adjustments of PROMPT_COMMAND, but it may fail when another framework saves the value of PROMPT_COMMAND in another variable. For such a case, we process our hooks only when the hooks are directly called from the top level of PROMPT_COMMAND. The detail is explained in the commit message.

[akinomyoga]

A test seems to fail in CI, though it works in my environment with Bash 5.2:

not ok 6 __bp_install_prompt_command should adjust modified PROMPT_COMMAND
# (in test file test/bash-preexec.bats, line [11](https://github.com/rcaloras/bash-preexec/actions/runs/4400455159/jobs/7705766093#step:4:12)6)
#   `if (( ${#PROMPT_COMMAND[@]} == 2 )); then' failed
# /tmp/bats.2795.src: line 116: PROMPT_COMMAND: unbound variable

I guess this would be related to the version difference of Bash, but I'm not sure how to run bats with the specified version of Bash. As far as I have looked inside the source code of bats, the path to Bash seems to be hardcoded...

Details

$ head -1 /usr/bin/bats /usr/libexec/bats-core/*
==> /usr/bin/bats <==
#!/usr/bin/bash

==> /usr/libexec/bats-core/bats <==
#!/usr/bin/bash

==> /usr/libexec/bats-core/bats-exec-file <==
#!/usr/bin/bash

==> /usr/libexec/bats-core/bats-exec-suite <==
#!/usr/bin/bash

==> /usr/libexec/bats-core/bats-exec-test <==
#!/usr/bin/bash

==> /usr/libexec/bats-core/bats-format-cat <==
#!/usr/bin/bash

==> /usr/libexec/bats-core/bats-format-junit <==
#!/usr/bin/bash

==> /usr/libexec/bats-core/bats-format-pretty <==
#!/usr/bin/bash

==> /usr/libexec/bats-core/bats-format-tap <==
#!/usr/bin/bash

==> /usr/libexec/bats-core/bats-format-tap13 <==
#!/usr/bin/bash

==> /usr/libexec/bats-core/bats-preprocess <==
#!/usr/bin/bash

[akinomyoga]

I have directly modified bats and could reproduce the error with Bash 5.0. I have fixed the CI test.

[akinomyoga]

Just to clarify, I mentioned mc (Midnight Commander) in the original post to explain the background, but the problem is not specific to mc. The problem happens with any commands that are added to PROMPT_COMMAND after the shell startup.

@rcaloras @dimo414 Could you take a look at this PR? If you'd like separate PR for each commit, I can create separate PRs.

[zktaiga]

@rcaloras I'm hitting this exact issue on Bash 5.2 with direnv + atuin. When direnv modifies PROMPT_COMMAND after bash-preexec sources, the __bp_install_string persists in the array and removes the DEBUG trap on every prompt, breaking atuin's history capture. This fixes it. Any blocker to merging this?

And of course thanks @akinomyoga for the fixes.