Strange xterm initial output

User Support General
1

Hi,

Many times when I launch an xterm session using a desktop shortcut, in a minimalist VM named ‘hdd’, I see this:

root
ooot
ooot
toot
@oot
hoot
doot
doot
:oot
~oot
 oot
#oot
root@hdd:~ #

Instead of only:

root@hdd:~ #

FWIW, my PS1 is:

\[18d91155385d9f3514b28d5993b817b833[0m\]\[18d91155385d9f3514b28d5993b817b833[48;5;124m\]\[18d91155385d9f3514b28d5993b817b833[1;33m\]\u\[18d91155385d9f3514b28d5993b817b833[40m\]\[18d91155385d9f3514b28d5993b817b833[1;37m\]@\[18d91155385d9f3514b28d5993b817b833[1;35m\]\h\[18d91155385d9f3514b28d5993b817b833[1;37m\]:\[18d91155385d9f3514b28d5993b817b833[1;32m\]\w\[18d91155385d9f3514b28d5993b817b833[1;31m\] #\[18d91155385d9f3514b28d5993b817b833[0m\]

If I launch xterm as user, I see:

user
sser
eser
rser
@ser
hser
dser
dser
:ser
~ser
 ser
>ser
user@hdd:~ >

It doesn’t happen all the time, but quite often, especially for root.

What is the reason/fix for this?

2 Likes
2

I have also seen this happen, although only once so far.

1 Like
3

I sometimes see:

u
s
e
r
@
t
e
s
t
:
~
$

This is not a new thing for me, but occasional only.

I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.

1 Like
4

What is the reason for this?
Is there a fix?

5

Time to run “reset”!

6

Usually the cause is “a program has output weird ANSI sequences”. This can happen if you cat or more/less a binary file, for example. Fixed by running “reset” in the affected terminal.

1 Like
7

After the initial appearance, everything seems fine.

I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.

1 Like
8

Hmmm… never experienced that… and cannot think of a reason for it.

9

@barto

Usually the cause is a program has output weird ANSI sequences.

Strange… I have seen this only in Qubes, not on bare-metal Linux.

Fixed by running reset in the affected terminal.

I guess I somehow need to run it automatically after starting xterm. Any ideas?

10

Is there any customisation in the bashrc or profile files that could be generating output?

The rest may not be helpful...

I have faint memories of problems of shells-within-shells in xterm, causing strange output like this (in vanilla linux). Maybe it a problem with an rc or profile scripts creating terminal-specific output.

Maybe it needs checking details of what is being exec’ed in the .desktop file, which could be running at least one extra shell. Is it plain qvm-run or does it have the “–no-shell” arg?
Although that should not send/affect output to the shell inside the xterm window, unless via the environment… and the various xterm args that decide how the shell gets run… and depending on the specific linux variant.

I fear the complexity is why the memories have been suppressed.

11

@phceac

Is there any customisation in the bashrc or profile files that could be generating output?

user@hdd:~ > tail -1 .bashrc 
[ -f "${HOME}/.bash_customizations" ] && . "${HOME}/.bash_customizations"

user@hdd:~ > cat .bash_customizations 
# .basrc

PS1='\[6ab61d7525962f18e6b4ed024055299233[0m\]\[6ab61d7525962f18e6b4ed024055299233[40m\]\[6ab61d7525962f18e6b4ed024055299233[1;36m\]\u\[6ab61d7525962f18e6b4ed024055299233[40m\]\[6ab61d7525962f18e6b4ed024055299233[1;37m\]@\[6ab61d7525962f18e6b4ed024055299233[1;35m\]\h\[6ab61d7525962f18e6b4ed024055299233[1;37m\]:\[6ab61d7525962f18e6b4ed024055299233[1;32m\]\w\[6ab61d7525962f18e6b4ed024055299233[1;36m\] >\[6ab61d7525962f18e6b4ed024055299233[0m\] '

user@hdd:~ > cat /etc/X11/Xresources/x11-common
! $Id$

! load color-specific resources for clients that have them
#ifdef COLOR
*customization: -color
#endif

! make Xaw (Athena widget set) clients understand the delete key
! this causes problems with some non-Xaw apps, use with care
! *Text.translations: #override ~Shift ~Meta <Key>Delete: delete-next-character()
*.dpi: 200
*renderFont: true
*faceName: Monospace bold
*faceSize: 12
*selectToClipboard: true
*.vt100.locale: true
*.vt100.saveLines: 10000

*allowTitleOps: false
*Title: CLIENTHOST

*.vt100.foreground: white
*.vt100.background: rgb:33/33/33

! black
*.vt100.color0:  rgb:0/0/0
! red3
*.vt100.color1:  rgb:c5/0/0
! green3
*.vt100.color2:  rgb:9a/cd/32
! yellow3
*.vt100.color3:  rgb:e5/a5/0a
! dark blue
*.vt100.color4:  rgb:75/a0/ff
! magenta3
*.vt100.color5:  rgb:a5/5f/af
! cyan3
*.vt100.color6:  rgb:0/cc/cc
! gray90
*.vt100.color7:  rgb:c2/bf/a5
! gray50
*.vt100.color8:  rgb:8a/7f/7f
! red
*.vt100.color9:  rgb:ff/55/55
! green
*.vt100.color10: rgb:89/fb/50
! yellow
*.vt100.color11: rgb:ff/ff/0
! light blue
*.vt100.color12: rgb:7d/b8/ff
! magenta
*.vt100.color13: rgb:ff/44/ff
! cyan
*.vt100.color14: rgb:55/ff/ff
! white
*.vt100.color15: rgb:ff/ff/ff

root@hdd:~ # cat /root/.bashrc 
# .bashrc

HISTCONTROL=ignoreboth

PS1='\[6ab61d7525962f18e6b4ed024055299233[0m\]\[6ab61d7525962f18e6b4ed024055299233[48;5;124m\]\[6ab61d7525962f18e6b4ed024055299233[1;33m\]\u\[6ab61d7525962f18e6b4ed024055299233[40m\]\[6ab61d7525962f18e6b4ed024055299233[1;37m\]@\[6ab61d7525962f18e6b4ed024055299233[1;35m\]\h\[6ab61d7525962f18e6b4ed024055299233[1;37m\]:\[6ab61d7525962f18e6b4ed024055299233[1;32m\]\w\[6ab61d7525962f18e6b4ed024055299233[1;31m\] #\[6ab61d7525962f18e6b4ed024055299233[0m\] '

root@hdd:~ # cat /root/.profile 
# ~/.profile: executed by Bourne-compatible login shells.

if [ "$BASH" ]; then
  if [ -f ~/.bashrc ]; then
    . ~/.bashrc
  fi
fi

Is it plain qvm-run […]

Yes:

Exec=qvm-run -u root hdd xterm
12

Would be great to track down how/why this happens :+1:

Just curious, what’s the story with the embedded text in your PS1?

1 Like
13

@Euwiiwueir

the embedded text in your PS1

What do you mean?

14

Maybe it doesn’t show up over email? Both times you’ve printed your PS1=..., on Discourse it appears to include a repeated text garble, looks like a hash code or something like that.

3 Likes
15

@Euwiiwueir

Thanks for pointing this out. I wasn’t aware that this forum software renders user input incorrectly.

Check this to see the original:

https://paste.opensuse.org/pastes/7a74f5bb80c5

2 Likes
16

Huh. It appears to be substituting a 32 byte hex string in place of \0. It is a pretty strange Discourse escaping bug, if that’s what’s going on.

1 Like
17

Might be some extreme email sanitisation. I do slightly less incomprehensible things if I send email from php containing user input, but with lots of simple replacement.

Now we got (hopefully) past that, I failed to reproduce any weirdness in a debian-12-minimal appVM with just the prompt. The Xresources looks innocuous - surely it couldnt insert output…?

Another question: do your ooots-toots show any of your exotic prompt colouring?

18

@phceac

Another question: do your ooots-toots show any of your exotic prompt colouring?

Yes, all of it.

19

I think I did not expect that. I hoped maybe the spurious first characters would be plain.

Does it mean bash is emitting them as a real part of the prompt ?

Until now, I was thinking maybe a $TERM mismatch somewhere between the xterm and the bash running in the tty. I think I noticed that debian and fedora have different terminal types in a user xterm, but that should(?) only be relevant for “open console” where the xterm is in a different qube…

A mystery!

20

@phceac

Does it mean bash is emitting them as a real part of the prompt ?

No idea. I suppose it is a drawing problem - something relating to the interaction between the overall Qubes system and xterm.