Re-adjust `PROMPT_COMMAND` when `PROMPT_COMMAND` is modified elsewhere

akinomyoga commented 1 year ago

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 fe5aedb3368d78fc47e017ceffca1d8265cdef0d, I refactored __bp_sanitize_string to include some processing that has been done outside of it. (such as that of #128), to use the function in implementing the string manipulation of PROMPT_COMMAND.
Commit 299080e32ac407a6d4c770170541f309d470aeb3 is a workaround for shopt -u extglob. The problem is explained in the code comment.
Commit c85de1bc66f9311e7cf3874f58823704e4b2aec8 is the main part of this patch, which re-adjusts PROMPT_COMMAND.
Commit 9c669e63ce430bd108339863a54e6857c5398840 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 commented 1 year ago

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...

```bash $ 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 commented 1 year ago

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

akinomyoga commented 6 months ago

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.

rcaloras / bash-preexec

Re-adjust `PROMPT_COMMAND` when `PROMPT_COMMAND` is modified elsewhere #143