The array or string type of the PROMPT_COMMAND variable is not respected by `mcfly init bash` (and in fact erases it if it's an array)

[pmarreck]

I have multiple Bash shell extensions that mess with PROMPT_COMMAND:
bash-preexec, mcfly, direnv, and starship.

PROMPT_COMMAND is either a Bash array (ideally), or a string with ";" separators. The former is preferred, but the latter should be respected, if that's how it was initialized.

https://github.com/rcaloras/bash-preexec is a system to manage preexec functions similarly to zsh, by setting up a Bash array of precmd_functions that are run from PROMPT_COMMAND.

Anyway, both Starship (I will be reporting this bug there too) and mcfly do not respect a PROMPT_COMMAND that is an array; the logic checks for its existence only (not whether it's a string or an array) and simply overwrites it if [[ ! "$PROMPT_COMMAND" =~ "mcfly_prompt_command" ]] (which obviously is undefined on an array).

Direnv does this more correctly; here is the output of direnv hook bash on my system (NixOS):

_direnv_hook() {
  local previous_exit_status=$?;
  trap -- '' SIGINT;
  eval "$("/nix/store/l97wg9p8zazih2r45g5fbz9b93rrj7p4-direnv-2.34.0/bin/direnv" export bash)";
  trap - SIGINT;
  return $previous_exit_status;
};
if [[ ";${PROMPT_COMMAND[*]:-};" != *";_direnv_hook;"* ]]; then
  if [[ "$(declare -p PROMPT_COMMAND 2>&1)" == "declare -a"* ]]; then
    PROMPT_COMMAND=(_direnv_hook "${PROMPT_COMMAND[@]}")
  else
    PROMPT_COMMAND="_direnv_hook${PROMPT_COMMAND:+;$PROMPT_COMMAND}"
  fi
fi

As you can see, it respects PROMPT_COMMAND's that are Bash arrays. Bash 5.1 was the first to allow a PROMPT_COMMAND of type "bash array".

Please fix.

[pmarreck]

Related: starship/starship#5409

[akinomyoga]

Which version of mcfly do you use?

Anyway, both Starship (I will be reporting this bug there too) and mcfly do not respect a PROMPT_COMMAND that is an array;

The current version respects an array PROMPT_COMMAND.

the logic checks for its existence only (not whether it's a string or an array) and simply overwrites it if [[ ! "$PROMPT_COMMAND" =~ "mcfly_prompt_command" ]] (which obviously is undefined on an array).

There is no such a code in the current version.

[akinomyoga]

if [[ ";${PROMPT_COMMAND[*]:-};" != *";_direnv_hook;"* ]]; then
  if [[ "$(declare -p PROMPT_COMMAND 2>&1)" == "declare -a"* ]]; then
    PROMPT_COMMAND=(_direnv_hook "${PROMPT_COMMAND[@]}")

I think this is wrong. For example, when the setting is originally PROMPT_COMMAND=(my_prompt_command), it would become PROMPT_COMMAND=(_direnv_hook my_prompt_command), but then ";${PROMPT_COMMAND[*]:-};" is evaluated to be ;_direnv_hook my_prompt_command; which doesn't contain ;_direnv_hook; even though _direnv_hook is already registered. Even if one properly sets IFS=';', I must point out that the command separator is not necessarily ;, but a newline can also be used. Actually, a newline is more robust because cmd2 & ; cmd2 is a syntax error while cmd 2 & <newline> cmd2 is valid.

[pmarreck]

Interesting.

I manage my dependencies via Nix in both Linux and macOS so I have whatever version is on nixpkgs.

[akinomyoga]

I now remember that when we added the array PROMPT_COMMAND to Bash 5.1, we discussed how we do not break the existing Bash configurations that assume PROMPT_COMMAND to be scalar. We intended to make old Bash configurations using PROMPT_COMMAND to be forward compatible. Please read this thread in the bug-bash mailing list:

https://lists.gnu.org/archive/html/bug-bash/2020-08/msg00122.html

The solution for a new configuration using the array PROMPT_COMMAND not to break older configurations using the scalar PROMPT_COMMAND is described in this reply. The mcfly integration exactly follows the way suggested in the Bash mailing list:

mcfly/mcfly.bash

Lines 84 to 88 in 0c68c9f

	PROMPT_COMMAND[0]=${PROMPT_COMMAND[0]:-}
	# Note: We here use eval to avoid syntax error in Bash < 3.1. We drop
	# the support for Bash < 3.0, but this is still needed to avoid parse
	# error before the Bash version check is performed.
	eval 'PROMPT_COMMAND+=("$command")'

I think this is solely an issue of direnv integration breaking all existing Bash configurations that don't assume the array PROMPT_COMMAND. If direnv wants to insert its hook at the beginning of PROMPT_COMMAND, it cannot rely on the array PROMPT_COMMAND.