Thanks for the PR!

Making the command interpreter configurable would indeed be a nice feature (see #7). Unfortunately, this PR isn't quite the right approach for several reasons:

• All commands are still written to the same history database, which doesn't make sense if the interpreter can be changed between invocations. Using the history would mix commands for different interpreters which may not even be valid, or worse, which may be dangerous, in the currently selected one. A separate history is needed for each interpreter.
• This implementation breaks in a variety of ways when the text contains sequences like && or quotes, because those will be dumped unescaped into the Bash command.
• Not every interpreter conforms to the simple command line interface where any text that is appended to the interpreter command is executed.

In summary, a more sophisticated implementation is needed, probably in the form of a configuration file where multiple interpreters can be specified, and a UI to switch between them. But this would introduce a lot of complexity, and I'm honestly not convinced that would actually be worth it, to cover the relatively niche use cases I've seen so far.

That's totally fair! My use case was to make this tool possible, which meant I just needed to pass the string to some command and return the value back. This PR enabled that, but isn't great if, say, you wanted to run zsh instead of bash.