I run qvm-run -u root <AppVM> xterm & and qvm-run -u user <AppVM> xterm & from Dom0 to launch xterm in an AppVM as root or user, respectively.
I wanted to load different .Xresources files for root and for user, but they both load user’s /home/user/.Xresources even though
/home/user/.Xresources belongs to user:user with 600 permissions
/root/.Xresources belongs to root:root with 600 permissions
the /etc/X11/Xsession file seems to be designed to pull the logged-in user’s .Xresources via USRRESOURCES=$HOME/.Xresources
Interestingly, whenever I manually load an .Xresources file via xrdb -merge it appears to affect both root’s and user’s xterm display; that is, whichever .Xresources file was last loaded via xrdb -merge will affect any subsequent xterms launched from Dom0 via qvm-run.
I even tried to add xrdb -merge /root/.Xresources and xrdb -merge /home/user/.Xresources to the end of the respective ./bashrc script, but it didn’t seem to prevent both root and user from loading /home/user/.Xresources
NB: of course, all edits to /root/ were made from the TemplateVM level.
I reviewed the links, but didn’t see where it would address the issue where .Xresources settings seem to bleed across user and root sessions. Seems like they would/should be separate, but it seems the user’s .Xresources file gets applied to root and whatever .Xresources file I merge via xrdb -merge affects both sessions.
You might have better luck with this one asking on unix.stackexchange.com or similar, or maybe the Arch Linux or Ubuntu forums, as I suspect this has more to do with distribution-level configuration of the X server than with Qubes specifically. These days X runs as user, not root, and is generally expected to serve only a single user rather than multiple, and the X server has a single resource manager across all users; given all that it’s not super surprising you’d see resource spillover from user onto root. But it would be surprising if you couldn’t do what you’re trying to do. I suspect there’s a way to do it.
I figured it was more Qubes-specific because of the virtualization. Either way, I got it to work, but not via .Xresources. Here’s what I found:
/home/.Xresources is still important for controlling other parts of the global Xterm experience like font, font size, and copying selected text to the clipboard. There’s no way I could find to prevent this “resource spillover”.
Debian’s /home/user/.bashrc had more content than /root/.bashrc and that the former had configurations for different colored prompts as defined by the PS1 variable
Fedora’s .bashrc scripts do not contain any PS1 variables/settings.
The bashrc prompt (PS1 variable) seemed to apply to their respective user context (unlike .Xresources).
I could change the default text color via the last color code in PS1,
I tried to create gray by dimming white (\e[2;37m) but later found [\e[38;5;247m\] makes a decent light-gray that doesn’t cause previous lines to dim
The syntax for the PS1 variable is a little wacky and I don’t fully understand it even though I got it working how I wanted
Unlike scripting, there will be more [s than ]s
If extended text wraps around on the same line, you’ll need to re-assess your PS1 variable; likely a bracket should have been escaped, particularly after \$
Speaking of \$, I forgot to escape it, which caused it to show a dollar sign prompt regardless of user or root. Escaping the dollar sign causes it to return a # for root and $ for user.
Many PS1 generators had double dollar signs to escape non-printing sequences, but in all of my testing, it just inserted random numbers. Stripping all double dollar signs ($$) resolved this issue.
I don’t know what \e or \033 are, but apparently they’re interchangeable and have to prefix certain parts of the variable.
The following files should be modified in
TemplateVMs
/etc/skel/.Xresources to push Xterm settings to new AppVM’s /home/user/.Xresources
/home/user/.Xresources to apply the Xterm settings to the all of the TemplateVM’s xterm sessions
/etc/skel/.bashrc to push the PS1 variable to new AppVM’s /home/user/.bashrc by either uncommenting force_color_prompt OR manually-configuring it (if it does not exist in the stock .bashrc file)
/home/user/.bashrc to configure the PS1 variable for the TemplateVM’s user by either uncommenting force_color_prompt OR manually-configuring it if it does not exist
/root/.bashrc to configure the PS1 variable for root in both the TemplateVM and all derivative VMs
AppVMs
All new AppVMs created after the modifications above will inherit the correct settings.
All existing AppVMs created before the modifications above will need the following files modified
/home/user/.Xresources to apply the Xterm settings to the all of the TemplateVM’s xterm sessions
/home/user/.bashrc to configure the PS1 variable for the AppVM’s user by either uncommenting force_color_prompt OR manually-configuring it if it does not exist
### Username and hostname in green:
PS1='\e[32m\u@\h:\w\$ \e[0m'
### Username in red, hostname in green, path in yellow, and prompt symbol in blue:
PS1='\e[31m\u\e[32m@\h\e[33m:\w\e[34m\$ \e[0m'
### Bold blue for username and hostname, green for the current directory:
PS1='\e[1;34m\u@\h \e[1;32m\w\e[0m\$ '
For reference later if you want, some more information about this ancient and admittedly wacky syntax:
\e and \033 both represent what the ESC key on your keyboard inputs. \0nn is the syntax for octal numbers in bash and some other things. The octal 33 (hex 1B, decimal 27) is the ASCII code for ESC.