On Tue 23 Jul 2024 at 09:31:36 (-0400), Greg Wooledge wrote:
> On Tue, Jul 23, 2024 at 23:22:52 +1000, Keith Bainbridge wrote:
> > The day# in my command prompt increments when I start in the morning. Maybe
> > I need to press enter.
>
> That makes it sound like you're setting the YEAR et al. variables in the
> PROMPT_COMMAND variable.
>
> If that's the case, it's *less* wrong, but only a little bit. You still
> have the issue that the date might change while you're sitting at a
> stale shell prompt from yesterday, with stale date/time variables.
Actually, that is what I do want (the time—the date not so much).
That tells you when the last command finished. Press Return before
you start a command and you get some idea of how long it takes
to run. For the current time, press Return.
I think putting the time±date in one's prompt is pretty popular,
judging by the number of ways of specifying it are listed in
man bash under PROMPTING. As well as employing those special
characters for the time elements, you can use the format specifiers
from the date command if you prefer: just wrap then in the \D{…}
special "character".
I use both myself: just the 24-hour time in xterms (where I have
xclock showing "Tue 23" and a swissclock for good measure), but
in VCs I include Tue23 because there's no other calendar reminder.
case "$TERM" in
*linux*)
PS1+='\H!\u \D{%a%d %T} \w\$ \['$(tput sgr0)'\]'
;;
*)
PS1+='\H!\u \t \w\$ \['$(tput sgr0)'\]'
;;
esac
(Note: the += is because my PS1 already has colour and error code
information within it. Also, confusingly, %T and \t both yield
24-hour times in their respective positions.)
> Really, the fundamental problem here is that you should not be storing
> date/time information in long-lived variables, and then trying to use
> those variables at an indeterminate point in the future.
>
> Anything that needs to act upon the current date should fetch the current
> date immediately before acting.
Cheers,
David.
