Detect readonly HISTTIMEFORMAT about bash-preexec HOT 4 CLOSED

It sounds like it would be impossible for bash-preexec to work correctly when HISTTIMEFORMAT is readonly. Given that, would it make sense to print one error at instal time and then refuse to install the debug trap and PROMPT_COMMAND? The problem with printing an error on every command is the user is left wondering who is printing it, and it's very hard to diagnose since they don't know the implementation of bash-preexec. If you say something like "bash-preexec: readonly HITTIMEFORMAT not supported" the user has a good chance of fixing it themselves.

from bash-preexec.

The short-term fix is to not do that :)

I'm inclined to agree with this - yes bash-preexec could suppress this error message, but the behavior would still be broken. https://stackoverflow.com/a/11248484 has similar advice.

I did come across this article which recommends making HISTTIMEFORMAT readonly, but it seems like security-through-obscurity to me; bash --norc would evade it, as jordanm notes on the SO thread.

from bash-preexec.

@gnachman I think failing at install time and printing a helpful error message is probably the best option here. We could add a function to check this at: https://github.com/rcaloras/bash-preexec/blob/master/bash-preexec.sh#L281.

How does that help your issue downstream in iTerm2 though? Is it simply better since the user can probably fix themselves?

from bash-preexec.

I agree that looks like a good place to put the check. Print an error message and return a code I can check. It's better for me because the user can help themselves instead of filing an issue 😄

from bash-preexec.