Recommended way to avoid / replace the command being run?

[samuell]

I want to capture the command and run it through my own software, and so avoid bash running the command at all, since that would mean it runs twice (once through my own software and then by bash).

What is the recommended way to do this with bash preexec?

[akinomyoga]

bash-preexec doesn't provide such a feature.

You could rebind RET using Bash's standard way as bind -x '"\r": your-command'. In addition, you might need to also rebind other keys that run commands, such as "\C-o" and "\C-x\C-e". But this is unrelated to bash-preexec and achievable without bash-preexec.

Technically there is another way to achieve that by enabling shopt -s extdebug and returning non-zero exit status in the DEBUG trap when the command shouldn't be run, but I wouldn't recommend this because this would require implementing more complicated and detailed control on the entire shell execution.

[d630]

Years ago, I came up with https://github.com/d630/bpx when I was working with bash-preexec. It's outdated and has never been reviewed, but it can potentially help in one way or another here

[samuell]

Thanks for the feedback @akinomyoga and @d630 ! I'll have a look at bpx!

Also, for the reference, I found I had earlier done something which seems like what you describe in the end, @akinomyoga , with the following hack (where scicmd -c is my own tool in this case):

#!/bin/bash
function scish() {
    export PS1="\033[32mscish > \033[39m"
    shopt -s extdebug
    trap 'if [[ ! $BASH_COMMAND == ls* && ! $BASH_COMMAND == cd* && ! $BASH_COMMAND == pwd* && ! $BASH_COMMAND == compopt* ]]; then scicmd -c "$BASH_COMMAND"; false; fi' DEBUG
 }

I hear what you say about potentially other unwanted consequences for the execution though, which I totally don't fully understand.

[akinomyoga]

I hear what you say about potentially other unwanted consequences for the execution though, which I totally don't fully understand.

extdebug makes the DEBUG trap apply recursively in subshells.

$ ls -l "$(type -p bash)"  # type -p bash will be sent to your command, and ls receives an empty argument.

Also, the DEBUG trap doesn't apply to every shell construct and BASH_COMMAND isn't ensured to contain the complete shell construct. Some parts of one command might be executed in Bash while the other parts of the command are executed in your command handler, which I guess is not what you try to achieve.

# a.txt is expected to get two lines, hello and world.
# I suspect a.txt becomes empty with your setting.
$ { echo hello; echo world; } > a.txt; ls -l a.txt

# "hello" and "world" are expected to be printed.
# I doubt your command handler properly handles this.
$ for a in hello world; do echo "$a"; done

Programmable completions and custom widgets for the interactive settings will also be sent to scicmd, which is probably unexpected. These are not specific to extdebug, but it becomes more complicated when the DEBUG trap is not set.

$ function _cmd { COMPREPLY=(hello); }; complete -F _cmd cmd
$ scish # enable extdebug and your DEBUG trap
$ cmd h[TAB]  # hello is expected to be completed, but it's not with your setting.

$ bind -x '"\C-t": echo "$READLINE_LINE" > a.txt'
$ scish # enable extdebug and your DEBUG trap
$ aaaaa[C-t]
$ ls -l a.txt  # "aaaaa" should be saved in a.txt, but I suspect it becomes empty with your framework.

The behavior of the DEBUG trap totally changes when extdebug is turned on. This means that if an interactive shell framework using the DEBUG trap of the normal behavior (without extdebug) is loaded in the shell (and even if you add exceptions for the framework to the BASH_COMMAND checks in the trap), extdebug will break the framework. More specifically, without extdebug, a shell function can define a DEBUG trap local to the current call of the function. However, with extdebug, the framework cannot define a local DEBUG trap naively. You will need to emulate those local DEBUG trap within your trap handlers, which will be very complicated.