Skip to content

__bp_preexec_invoke_exec "$_" printed when running multiple commads #116

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

Closed
clupasq opened this issue Jul 6, 2021 · 3 comments
Closed

Comments

@clupasq
Copy link

clupasq commented Jul 6, 2021

I originally discovered this when using bash-it, and posted an issue there as well: Bash-it/bash-it#1895
I'm reproducing the relevant bits:

Ctrl + X, Ctrl + E allows opening the current bash command in the default editor.
I sometimes to this to enter multiple commands (separated by newline).
After saving and exiting the editor, the commands are run as expected.

For the examples below I'll consider the following commands:

echo 1
echo 2
echo 3

Expected Behavior

What is expected is that only the commands and their results are being printed to the console.
Here's an example of such an interaction without bash-it:

$> echo # <== at this point I fired up the editor to type in the aforementioned command(s).
echo 1
1
echo 2
2
echo 3
3

Current Behavior

Here's what's being printed when using bash-it:

❯ echo # <== using the editor to type in the commands again
echo 1
__bp_preexec_invoke_exec "$_"
1
echo 2
__bp_preexec_invoke_exec "$_"
2
echo 3
__bp_preexec_invoke_exec "$_"
3

I'm not sure if this is a bug; it may be the intended behavior, so please confirm.

Steps to Reproduce

  1. Press Ctrl + X, Ctrl + E on the command line
  2. Use the editor to enter more than one command (newline separated)
  3. Save && exit
  4. Inspect the output. You're likely to see the expected output, plus some __bp_preexec_invoke_exec "$_" lines between each command and its output.

Environment

  • Bash-it version used: dev (git SHA: 2444a57 on 2021-06-10T16:04:56+03:00)

  • List of enabled plugins, themes and aliases (use bash-it show (plugins/themes/aliases)): no plugins, no aliases, powerline-multiline theme (also tested with themes bobby & nwinkler and got the same result)

  • bash-it doctor output:

  • Bash version: 5.0.3(1)-release

  • Operating System and version: Debian 10 (buster)

@akinomyoga
Copy link
Contributor

This is a bug of Bash <= 5.0, which happens when the command is executed through fc or C-x C-e. It was fixed in Bash 5.1.

The original report to Bash is https://lists.gnu.org/archive/html/bug-bash/2020-04/msg00016.html. This was fixed in commit e34adc2@savannah.gnu.org:bash.

Here are the corresponding ChangeLog and diff in Bash:
            4/3
            ---

trap.c
  - run_debug_trap: allow suppress_debug_trap_verbose being set to
    turn off `set -v' temporarily while executing the DEBUG trap (if
    it's set)

builtins/fc.def
  - set suppress_debug_trap_verbose so set -v won't be in effect while
    the DEBUG trap runs. Most recently reported by Ami Fischman
    <[email protected]>; originally raised by Boruch Baum
    <[email protected]> back in 10/2017
diff --git a/builtins/fc.def b/builtins/fc.def
index f7b1e0ec..6951a687 100644
--- a/builtins/fc.def
+++ b/builtins/fc.def
@@ -86,9 +86,11 @@ $END
 extern int errno;
 #endif /* !errno */

-extern int unlink __P((const char *));
+extern int unlink PARAMS((const char *));

-extern FILE *sh_mktmpfp __P((char *, int, char **));
+extern FILE *sh_mktmpfp PARAMS((char *, int, char **));
+
+extern int suppress_debug_trap_verbose;

 /* **************************************************************** */
 /*^I^I^I^I^I^I^I^I    */
@@ -470,7 +472,9 @@ fc_builtin (list)
   add_unwind_protect (xfree, fn);
   add_unwind_protect (unlink, fn);
   add_unwind_protect (set_verbose_flag, (char *)NULL);
+  unwind_protect_int (suppress_debug_trap_verbose);
   echo_input_at_read = 1;
+  suppress_debug_trap_verbose = 1;

   retval = fc_execute_file (fn);
   run_unwind_frame ("fc builtin");
diff --git a/trap.c b/trap.c
index 8d605b04..6db920a6 100644
--- a/trap.c
+++ b/trap.c
@@ -121,6 +121,9 @@ int wait_signal_received;

 int trapped_signal_received;

+/* Set to 1 to suppress the effect of `set v' in the DEBUG trap. */
+int suppress_debug_trap_verbose = 0;
+
 #define GETORIGSIG(sig) \
   do { \
     original_signals[sig] = (SigHandler *)set_signal_handler (sig, SIG_DFL); \
@@ -1137,9 +1140,7 @@ run_debug_trap ()
 #endif

       old_verbose = echo_input_at_read;
-#if 0^I/* not yet */
-      echo_input_at_read = 0;
-#endif
+      echo_input_at_read = suppress_debug_trap_verbose ? 0 : echo_input_at_read;

       trap_exit_value = _run_trap_internal (DEBUG_TRAP, "debug trap");

diff --git a/trap.h b/trap.h
index 49a91222..bf2c9a1e 100644
--- a/trap.h
+++ b/trap.h
@@ -64,6 +64,7 @@ extern int trapped_signal_received;
 extern int wait_signal_received;
 extern int running_trap;
 extern int trap_saved_exit_value;
+extern int suppress_debug_trap_verbose;

 /* Externally-visible functions declared in trap.c. */
 extern void initialize_traps PARAMS((void));

I don't think there is a way to work around this bug from the setting unless we give up using the DEBUG trap. However, there is no other ways to implement preexec in lower versions of Bash.

@clupasq
Copy link
Author

clupasq commented Nov 25, 2024

Closing, as this is a bash bug.

@clupasq clupasq closed this as completed Nov 25, 2024
@akinomyoga
Copy link
Contributor

The older Bash versions will not be fixed, so maybe we can document this as a limitation in older versions of Bash (<= 5.0).

@clupasq Probably, you also want to comment on the original issue, Bash-it/bash-it#1895?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants