On 12/20/23 10:58, Bart Schaefer wrote:
So what are you planning to do, re-source your .zshrc every time it changes?
No.
The plan to translate %F / %K just seems unworkable to me.
It did function and I was getting identical behavior on the old and new systems.
At least until the drive in the ancient system died. The owner has posthumously decided that the system didn't need to be retained. Go figure.
So this is now an academic discussion.
OK, but you do that with the %(?.true.false) escape, right?
Yes.
You're not changing the actual assignment to PROMPT= every time?
PROMPT / PS1 and RPROMPT will be initialized with different values as the shell is started when opening a new terminal emulator, entering a nested shell, forking !shell from in vi(m) et al.
But you are correct that the dynamic nature of any invocation is via the %(?.true.false) form.
The contents of the PROMPT / PS1 / RPROMPT will likely not change in any given invocation of the shell. But what those values output can be fairly dynamic.
The latter is what I mean by "doesn't change very often" (if you're using nothing but 4.2 features).
Fair enough. I was thinking about the dynamic output of what you are considering to be the static input.
(%) is a parameter expansion flag, it means "treat the rest of this expansion like a prompt".
Interesting.
Using :- like that means "if the empty parameter name is unset" (which is always the case).
ACKI make judicious use of that. But I wasn't sure if it was the same with the "(%)" or if that fundamentally altered it.
So if %F is not supported in a prompt, that substitution will return something containing the literal string "red" somewhere.
Hum.This makes me wonder -- academically -- if I could create a bunch of variables that are effectively place holders for each color and then reference them in the prompt as necessary. But doing so intelligently wherein if it's supported, use the %F{...} method or fall back to the manually entered control codes. But I feel like that might be an abstraction inversion. :-/
I'll probably poke at this at some point to make sure I truly understand what is possible and then evaluate if it's worth doing or not. -- Sometimes there is merit to an abstraction inversion as it helps foster fuller understanding of some concepts as an academic exercise.
As for the system on the failed drive, I manged to do a full bare metal system recovery into a VM hours before the owner decided to decommission the system. C'est la vie.
Thank you Bart and Roman, you've both given me things to think about as I reflect on and learn from this experience. :-)
-- Grant. . . .
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature