profile.d: prepend purple hexagon to PS1 rather than overwriting it

[juhp]

Importantly this means the traditional Red Hat style prompt is not forced onto all other OS toolboxes as well.

[juhp]

I tested this locally in a VM and it works for me both with bash and zsh in fedora-toolbox:41
and ubuntu-toolbox:24.04

[softwarefactory-project-zuul]

Build succeeded.
https://softwarefactory-project.io/zuul/t/local/buildset/6426b391ccd6403abb615593eb988e79

✔️ unit-test SUCCESS in 6m 34s
✔️ unit-test-migration-path-for-coreos-toolbox SUCCESS in 3m 29s
✔️ unit-test-restricted SUCCESS in 5m 34s
✔️ system-test-fedora-rawhide SUCCESS in 37m 44s
✔️ system-test-fedora-40 SUCCESS in 37m 05s
✔️ system-test-fedora-39 SUCCESS in 38m 06s
✔️ system-test-fedora-38 SUCCESS in 37m 11s

[glemco]

This doesn't work if one overrides the PS1 in a user file (e.g. bashrc), as those are sourced after the ones in /etc/profile.d and would wipe the PS1 change introduced here.
A more robust way could be to override the PROMPT_COMMAND (#1357 (comment)), although I'm not fully sure about the implications on shells not supporting it as an array

[debarshiray]

Thanks for working on this, @juhp !

I didn't mean to ignore this. I have been trying to get a new dot-zero release out, and keep hitting various obstacles, and I am always paranoid about anything that touches the shell start-up scripts because every operating system does things so differently.

It will be good to try it out on host and container combinations of the operating systems that we claim to support. ie., Arch, Fedora, RHEL and Ubuntu. I know, the matrix isn't small. :)

What do you think of the PROMPT_COMMAND idea, and perhaps falling back to the current approach if PROMPT_COMMAND is not an array?

The current approach with the hexagon doesn't work on some host/container combinations. eg., Arch and Ubuntu, but I forgot the details. I wonder if this improves that situation or something can be done to improve it.

[juhp]

This doesn't work if one overrides the PS1 in a user file (e.g. bashrc), as those are sourced after the ones in /etc/profile.d and would wipe the PS1 change introduced here.

@glemco that is already the case today and I might even call it a feature: users should be able to override toolbox PS1 if they want, and it is particularly necessary currently since the current toolbox prompt is rather restrictive and insufficient (the biggest problem being that it is does not distinguish different toolboxes clearly).

[juhp]

I have been trying to get a new dot-zero release out, and keep hitting various obstacles, and I am always paranoid about anything that touches the shell start-up scripts because every operating system does things so differently.

I would love to see a 0.1 release finally :-)

It will be good to try it out on host and container combinations of the operating systems that we claim to support. ie., Arch, Fedora, RHEL and Ubuntu. I know, the matrix isn't small. :)

I feel a better approach might be to put out snapshots and test them in Rawhide, etc (early in the development cycle) for broader testing: it is not really practical for an individual to test all possible host × container matrices realistically.
Or ideally it should be done in CI or automated of course. But I will try to do some testing later.

What do you think of the PROMPT_COMMAND idea, and perhaps falling back to the current approach if PROMPT_COMMAND is not an array?

I reopened #1514 which was actually the original motivation or wart I wanted to fix, since currently the binary PS1 makes it harder than necessary to override PS1 for users or bash-color-prompt in Fedora, etc. That PR may be a simpler first step since it doesn't change the current PS1 much (it just changes from a binary to ascii string).

I need to think more about PROMPT_COMMAND in this context.

The current approach with the hexagon doesn't work on some host/container combinations. eg., Arch and Ubuntu, but I forgot the details. I wonder if this improves that situation or something can be done to improve it.

I see, maybe there should be an issue to track that?