[SOLVED] systemd (not SSH) prepending diagnostic string to $PS1

barthel · 2025-10-15 19:39:34

Context: For years, I've been using evilvte with 4 configurations to visibly distinguish my terminals (yellow on black for "normal", yellow on red for "root", white on blue for "ssh", and white on purple for "ssh-root"). The terminal environments have matching icons to distinguish them on the taskbar as well.

I have a small helper script using zenity to provide a selection dialog of my local network hosts. This snippet shows the ssh / sudo commands in use.

case $1 in
    local    ) evilvte ;;
    root     ) evilvte.$1 -e sudo --login su ;;
    ssh      ) evilvte.$1 -e ssh -t $(get_host) ;;
    ssh-root ) evilvte.ssh.root -e ssh -t $(get_host) sudo su ;;

My ~/.ssh/config has the options for each of my 4 current networked systems. (That way I can use the same config on each system.)

This setup has worked since at least September 2019. (That's the earliest archive copy of the script on my primary system.)

The issue: After updating 2 systems yesterday, I ssh'd from my main system to the media server. To my surprise, the $PS1 prompt was preceded by several strings of diagnostic info, to wit:

]3008;start=cdf965fe-740d-4f8d-9b7b-7fff2ff4cd73;user=myuser;hostname=myhost;machineid=b47b9cab591c47b287b15183a1e0a9ad;bootid=3e78bd2c-e51d-4f13-9c5e-541b0dabb783;pid=60793;type=shell;cwd=/home/myuser[myhost]

(The first character appears to be a unicode glyph for 001B, or ESC.) Also, I substituted "myuser" and "myhost" for the actual values. (basic security through obfuscation)

Additional symptoms/diagnostics:

This string only appears on a normal user ssh, e.g. ssh -t myremote. The equivalent ssh-root does not include this string: it prompts for my sudo password and drops to a normal $PS1 prompt. It does not appear on either "local" or "root" shells.
The string is repeated before each prompt, but the value of $PS1 is unchanged from what I set in my .bashrc.
If I launch a new shell from within this ssh shell, the new shell does not include the diagnostic text, just the normal $PS1 prompt.
This string does not appear when I ssh to either of the 2 systems that were not yet updated. I get the normal "Last login" string, then the normal $PS1 prompt.
The string does appear if I ssh from myhost back to myhost.
I get the same behavior whether I start the ssh session via command line or via my selection dialog. (So the problem isn't in my simple script...)
Using different terminals (xterm, qterminal, mate-terminal) worked normally and did not display the diagnostic string. I recompiled evilvte, but get the same results.
The only ssh upgrades were openssh (10.0p1-4 to 10.2p1-1) and libssh (0.11.2-1 to 0.11.3-1). No pacnew files were created, so I didn't revise any existing configuration files.
I attempted using the ssh -v options, but no relevant debug messages appeared.

Ideally, I'd like to track down the source of this text to eliminate it if possible.

Yes, I realize that the "easy" fix seems to be to use a different terminal. However, that would result in a significant loss of functionality which I depend on when maintaining all 4 systems. I've gone through about half of the terminals in the "List of Applications", but so far, none make the grade. Features I "need" are:

provided by an Arch package (I'm willing to use AUR or source if the code is stable and mature.)
easily supports multiple configurations (mate-terminal failed here because dconf keys are not easily portable. For evilvte, the configuration is stored in the executable and I can quickly compile 4 versions by symlinking to config.h...)
can use a user-defined icon for its titlebar and taskbar (mate-terminal failed here too, which is a shame. I had planned to switch to mate-terminal and actually have the relevant commands in the script... commented out, but they're there...)
supports transparency or pseudo-transparency (pseudo-transparency is better, because it uses the desktop background, not all the underlying windows)

The questions:
Does anyone know the source of the diagnostic strings?
Can anyone suggest other steps which may help me identify the issue?
Can anyone suggest an alternate terminal that meets my criteria above? (I'm going to continue exploring the "List of Applications", but I might inadvertently dismiss a viable option based on its overview.)

(I do have a kludge for now, but it's ugly: evilvte -e ssh myremote evilvte. This results in a second terminal with the normal $PS1. The first terminal is completely empty and closes immediately after the second terminal exits. The diagnostic strings never appear in either terminal.)

Oh, I should note that I'm primarily using LXQt, but include apps from other desktops as suit my needs...

Thanks in advance!!!

Last edited by barthel (2025-10-21 20:12:49)

seth · 2025-10-15 20:45:25

Does anyone know the source of the diagnostic strings?

Using different terminals (xterm, qterminal, mate-terminal) worked normally and did not display the diagnostic string. I recompiled evilvte, but get the same results.

Can anyone suggest other steps which may help me identify the issue?

The only ssh upgrades were

What about the non-ssh updates? The change seems to come from evilvte?

The string is repeated before each prompt, but the value of $PS1 is unchanged from what I set in my .bashrc.

What is your PS1? (the data might come as expansion of some other value?)

urxvt easily meets your requirements (using a patched version you can also have different background images to indicate the terminal) but for the "config" part - you'd have to discriminate the behavior w/ config switches on invocation.
alacritty might be interesting, but I don't think you can set different icons

barthel · 2025-10-16 11:29:23

I appreciate the quick response!

For an SSH session, I set

PS1='\[\e]0;\u@\h: \w\a\]\$ '

When I issue "echo $PS1" in the terminal, I get: 3008;start=57614b62-9a40-41dc-8911-1b073b083660;user=myuser;hostname=myhost;machineid=b47b9cab591c47b287b15183a1e0a9ad;bootid=3e78bd2c-e51d-4f13-9c5e-541b0dabb783;pid=91219;type=command;cwd=/home/myuser\[\e]0;\u@\h: \w\a\][\h] \$] (using color codes for emphasis instead of a code block)

As I said, the diagnostic info precedes every line of output, so it's not just with $PS1. (I had thought something was modifying PS1 too, but the value is unchanged.)

Since the diagnostic info doesn't appear when "sudo su" is included, I'm fairly certain that evilvte itself was not the issue. The git source code for evilvte and the aur package for vte-legacy have not changed since I first compiled them in June 2018. Even so, to ensure it wasn't an issue with another library, I did do a fresh compile - but the behavior was unchanged. I looked at the included libraries, but I didn't spot an obvious culprit. Here are the includes from config.mk:

VTEINC=-pthread -I/usr/include/vte-0.0 -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/pango-1.0 -I/usr/include/atk-1.0 -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/libpng16 -I/usr/include/pango-1.0 -I/usr/include/gio-unix-2.0/ -I/usr/include/cairo -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/harfbuzz -I/usr/include/freetype2 -I/usr/include/harfbuzz -I/usr/include/libdrm -I/usr/include/libpng16 
LIBS_VTE=-lgdk-x11-2.0 -lgtk-x11-2.0 -lvte
LIBS_VTE_L=

I should probably mention that all configuration for evilvte is done in the configuration files. I have 4 copies of config.h that specify the color combinations and the terminal "type". The 4 icons are set from within a modified evilvte.c that sets the desired icon file in gtk_window_set_icon_from_file(). i have a make script that symlinks each config to config.h before compiling the 4 binaries.

At this point, my best hope was that someone might know the source of the machineid and bootid in the diagnostic text. I've never seen them before and thought that might point me in the right direction.

I will take a closer look at urxvt again. I used to keep it as an alternative, but never actually used it in my day-to-day work. (In fact, when I finally replaced my hardware in July, I didn't include it on the fresh Arch install....)

Again, thanks so much for the feedback!

seth · 2025-10-16 14:14:30

You're getting this for

evilvte.ssh -e ssh -t $(get_host)

but not

evilvte.ssh.root -e ssh -t $(get_host) sudo su

You're not getting it for

xterm -e ssh -t $(get_host)

?
Do you get it for

evilvte.ssh.root -e ssh -t $(get_host)

or

evilvte.ssh -e ssh -t $(get_host) sudo su

?

barthel · 2025-10-16 21:07:37

seth - good questions. I obviously communicated poorly.

The only difference between the evilvte verrsions is the color scheme. (evilvte = yellow on black; evilvte.root = yellow on red; evilvte.ssh = white on blue; evilvte.ssh.root = white on purple). Each of these behaves the same way. With "-e ssh -t hostname", the diagnostic text appears. With "-e ssh -t hostname sudo su", the sudo password prompt appears, followed by a normal prompt upon success. The "$(get_host)" calls a function in my helper script which returns the host selected in the zenity dialog.

When I was comparing other terminals, I was sending only "ssh -t hostname" as the executable argument. (mate-terminal uses -x instead of -e....)

Thanks for the follow-up!

seth · 2025-10-16 21:32:43

I obviously communicated poorly.

No, I just wanted to make sure that this isn't specific to the single evilvte build.

sudo drops the environment (you should™ btw use "sudo -i", not "sudo su", but that's unrelated) so no surprises there.
Do you get this for

evilvte.ssh -e ssh -t $(get_host) bash

?
We could then seek to debug

evilvte.ssh -e ssh -t $(get_host) bash -x

and

tr '\0' '\n' < /proc/$(pidof evilvte.ssh)/environ

Finally (or firstly, feel free to just test this)

evilvte.ssh -e env TERM=xterm-256color ssh -t $(get_host)

(The update might have dropped the terminfo for evilvte)

barthel · 2025-10-17 11:49:17

seth wrote:

sudo drops the environment (you should™ btw use "sudo -i", not "sudo su", but that's unrelated) so no surprises there.

Au contraire! There is indeed a surprise!

On a whim, I first tested your suggestion to see if I should update the sudo commands in my script. I kept "--login" because that's the long form of the "-i" option. (One of the times when the short option isn't an obvious abbreviation...) When I did

evilvte.root -e sudo --login &

I got the login prompt, followed by the diagnostic text before $PS1. This means the issue isn't with ssh at all!

Next test, I went to my wife's system (one of the 2 that hadn't been updated yet) and issued the same command. No diagnostic text. (Really, just a sanity check to confirm that the cause was something in the update of my primary system.)

seth wrote:

Do you get this for
evilvte.ssh -e ssh -t $(get_host) bash
?

As expected, NO diagnostic text. I don't know why I didn't think to try using "bash" after I verified that including another invocation of evilvte... At the very least, this gives me a clean kludge. (Try saying that 3x fast!) But we've gone this far, let's see if we can trace it further...

seth wrote:

We could then seek to debug
evilvte.ssh -e ssh -t $(get_host) bash -x

I'm going to assume the key output we're seeking is

++ printf '\033]0;%s@%s:%s\007' myuser myremotehost '~'

followed by the PS1 prompt. Otherwise, I'll have to dump std error to a file... ;-) The parts that were still visible included alias and function definitions from .bashrc and related files.

For good measure, I issued "bash -x" in a terminal that had the diagnostic text. As far as I could tell from the limited buffer, the output was identical. However, since I was now in a sub-shell, the diagnostic text no longer appeared until I exited back to the original shell.

seth wrote:

and

tr '\0' '\n' < /proc/$(pidof evilvte.ssh)/environ

Running that in the ssh terminal with the diagnostic text yielded

USER=myuser
LOGNAME=myuser
HOME=/home/myuser
PATH=/usr/local/sbin:/usr/local/bin:/usr/bin
SHELL=/bin/bash
TERM=xterm
DISPLAY=localhost:10.0
MOTD_SHOWN=pam
MAIL=/var/spool/mail/myuser
XDG_SESSION_ID=7
XDG_SESSION_TYPE=tty
XDG_SESSION_CLASS=user
XDG_RUNTIME_DIR=/run/user/1000
DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus
SSH_CLIENT=192.168.nnn.nnn 5nnnn 3nnnn
SSH_CONNECTION=192.168.nnn.nnn 5nnnn 192.168.nnn.nnn 3nnn
SSH_TTY=/dev/pts/0

seth wrote:

Finally (or firstly, feel free to just test this)
evilvte.ssh -e env TERM=xterm-256color ssh -t $(get_host)
(The update might have dropped the terminfo for evilvte)

No joy there: the diagnostic text did not appear.

While we didn't pin down the source of the text, you did get me to the reasonable workaround of appending "bash" to my command. From a usage perspective, the biggest issue with the diagnostic text is that it obscured the shell output (and affected modifying commands). So I'm willing to mark this thread [SOLVED].

Solution recap, should anyone else refer to this thread:

local shell:      evilvte                                                  (unchanged)
local root shell: evilvte.root -e sudo --login bash                        (replace "su" w/ "bash")
ssh shell:        evilvte.ssh -e ssh -t $(get_host) bash                   (append "bash")
ssh root shell:   evilvte.ssh.root -e ssh -t $(get_host) sudo --login bash (replace "su" w/ "--login bash")
(I had dropped --login previously while diagnosing a $DISPLAY issue and never put it back. Sigh!)

Thank you!!!

seth · 2025-10-17 12:47:35

evilvte.ssh -e ssh -t $(get_host) bash -l

… you might get this w/ just

bash -l

(this runs a login shell which makes bash source other stuff, https://man.archlinux.org/man/bash.1#INVOCATION )

barthel · 2025-10-18 06:40:52

seth wrote:

evilvte.ssh -e ssh -t $(get_host) bash -l
… you might get this w/ just
bash -l
(this runs a login shell which makes bash source other stuff, https://man.archlinux.org/man/bash.1#INVOCATION )

Thanks! I'll have to check that out in more detail - I haven't had a usage case for that particular option before.

Then again, it might be moot. My .bash_profile (last modified May 2011):

#
# ~/.bash_profile
#

[[ -f ~/.bashrc ]] && . ~/.bashrc

If I'm interpreting the man page correctly, the only file that wouldn't be sourced is /etc/profile (and /etc/profile.d/*).

Yay! More homework! ;-)

And just because I'm a Pennsylvania Dutch weisenheimer:
I started with Slackware in the 90s. I remember the emacs vs. vim holy wars. You can't scare me with a couple of man pages. You might confuse me, but you can't scare me. ;-)

seth · 2025-10-18 08:09:26

I'm interpreting the man page correctly, the only file that wouldn't be sourced is /etc/profile (and /etc/profile.d/*)

Yes.

And just because I'm a Pennsylvania Dutch weisenheimer:

And do your elders know that you're playing with the devils modern technology over there in Missouri?

https://man.archlinux.org/man/zshall.1# … DOWN_FILES
https://man.archlinux.org/man/mpv.1

barthel · 2025-10-21 20:09:26

seth wrote:

And do your elders know that you're playing with the devils modern technology over there in Missouri?

Not a problem.

I'm up-country Dutch, not from the plain folk.
I'm the eldest in my line who is still living. ;-)

Back on topic: I finally got to follow through with your most recent suggestion and got an interesting result. (Weekend with too many commitments, major storms and a power outage.)

Using

evilvte.ssh -e ssh -t myhost bash

gave me a clean shell as previously reported.
Using

evilvte.ssh -s ssh -t myhost bash -l

brought back the diagnostic text, suggesting that the issue is in the /etc/profile hierarchy (and "bash -l" essentially spawns an unneeded process...)

Looking at "env | less", the only significant difference is that the bash -l variant includes

LANG=en_US.UTF-8
LC_COLLATE=C
DEBUGINFOD_URLS=https://debuginfod.archlinux.org

Now, the locale issue is on me: my personal .bashrc scripts don't set the locale environment. But the DEBUGINFOD led me to look at /etc/profile.d/* more carefully. (Context: in the old days, we used to "test -x", making "chmod 644" the easiest way to disable a script . So I previously ignored all the files in /etc/rc.d that didn't have execute permission. My error: /etc/profile uses "test -r" - the file need only be readable to be sourced.)

That led me to the source of the diagnostic text: 80-systemd-osc-context.sh has code that produces the diagnostic text. The giveaway is that each of the strings begins w/ "\033]3008;start="

SYSTEMD???!!! Of course it's systemd.....

The critical line in 80-systemd-osc-context.sh is where it sets PS0...

# PS0 is shown right after a prompt completed, but before the command is executed
    PS0='\033]3008;start=$systemd_osc_context_cmd_id$(__systemd_osc_context_common);type=command;cwd=$(__systemd_osc_context_escape "$PWD")\033\\'"${PS0:-}"
fi

This explains why the diagnostic text prepends EVERY output.

A quick search led me to: https://github.com/systemd/systemd/blob … CONTEXT.md from which I quote:

Status
This OSC sequence has been invented by the systemd project and is generated by systemd. Currently, no terminal application is known that consumes these sequences.

Right now, I haven't discovered how other terminals are suppressing this output, but given that "no terminal application is known that consumes these sequences", I'm going to regard this as unnecessary superfluous cruft. My best solution to eliminate it is to remove the symlinks in /etc/profile.d (and remove them again every time systemd is updated).

After posting, I will edit the topic to help with others searching for this problem. I can also revert the changes to my helper script to eliminate the extra processes.

Thanks again, seth!

Last edited by barthel (2025-10-21 20:28:39)

seth · 2025-10-21 20:30:53

=> https://github.com/systemd/systemd/issues/39133
==> https://github.com/systemd/systemd/issues/39114

Last edited by seth (2025-10-21 20:32:25)

barthel · 2025-10-22 07:25:17

seth wrote:

=> https://github.com/systemd/systemd/issues/39133
==> https://github.com/systemd/systemd/issues/39114

Thank you, again.

While I'm not at all surprised at the attitude of systemd developers who believe only they know the "one true way", I am gratified to see that removing the symlink after every systemd upgrade is a suggested solution.

The suggestion to set "TERM=dumb" is ridiculous, as it would break nearly every other program that references that variable.

Also the suggestion that the correct behavior for terminals is to ignore anything they don't understand is also ridiculous: it could lead to error messages silently disappearing into /dev/null.

I could go on, but it's at least 6 hours until I take my blood pressure medication again. I also have to confess that I wouldn't be adding anything new to the critique of systemd and its developers.

Here's a crazy idea: maybe we need to revisit the decision to kill TERMCAP. "Outdated, old and crusty" it may be, but it was a central repository for terminal capabilities and the control sequences to invoke them.

For now, kill 80-systemd-osc-context.sh. It's newfangled, immature and arrogant. As we used to post in alt.callahans, "Where did that soapbox come from?"

Also, when did I become a "Get off my lawn!" old geezer? Sigh.

(Funny, but that's how we did smileys in the 80s, but then we got in the habit of adding noses: ;-) )

seth · 2025-10-22 14:35:24

The suggestion to set "TERM=dumb" is ridiculous

Maybe export TERM=lennart …

B: systemd injects made up OSCs into the output
A: have you considered completely breaking your terminal?

We'll just pretend that L. meant that to be a joke, because the suggestion is too off the charts silly.

evilvte seems slightly bitrot, though.
wrt switching efforts, you're aware that you can change foreground and background colors with OSCs on many terminal emulators (ie. there's actually no need to do this w/ terminal configs, eg. my default foreground turns red when I enter a root shell)
If you want to try urxvt, probably also look at https://aur.archlinux.org/packages/rxvt … ide-glyphs (for better™ font handling)

Lone_Wolf · 2025-10-22 16:21:48

To block this permanently after deleting it : add a NoExtract entry to pacman.conf

NoExtract = etc/profile.d/80-systemd-osc-context.sh

(note that the missing slash before etc is intentional . see man pacman.conf for the reason)

barthel · 2025-10-22 18:53:21

Lone_Wolf wrote:

To block this permanently after deleting it : add a NoExtract entry to pacman.conf
NoExtract = etc/profile.d/80-systemd-osc-context.sh
(note that the missing slash before etc is intentional . see man pacman.conf for the reason)

Awesome! I'll put that on my wife's system now - hers is the last one to upgrade in this cycle!

And to think that I was just going to

touch /etc/profile.d/00-delete_systemd_symlinks

as a persistent reminder.

Thank you very much!!

barthel · 2025-10-22 20:16:06

seth wrote:

evilvte seems slightly bitrot, though.
wrt switching efforts, you're aware that you can change foreground and background colors with OSCs on many terminal emulators (ie. there's actually no need to do this w/ terminal configs, eg. my default foreground turns red when I enter a root shell)
If you want to try urxvt, probably also look at https://aur.archlinux.org/packages/rxvt … ide-glyphs (for better™ font handling)

Granted, evilvte is ancient. However, it was perfect for my previous desktop. (I bought it new ca. 2011/2012 and was still using it until July this year.)

I reinstalled urxvt last night for a test drive, but it was ignoring the command line options in favor of the values set in .Xresources. The options ARE listed in the --help, but maybe only the long forms are supported. I'll keep plugging at it for the next few days. The main one I need is the iconFile option to associate the icon with the correct color scheme & prompt. I doubt there's an OSC for that.

Ack! I remember typing all those escape sequences by hand...

Right now, I'm double-checking user initialization on my 3 remaining systems. I've already addressed locale settings for the ssh shells, but I'm experiencing what my wife calls "Chickie Murphy syndrome": cleaning one thing reveals that something else should be cleaned too, etc.

For the time being, I can continue with evilvte until I get urxvt or another terminal configured for my personal preferences. I'm quite satisfied with this result, especially since I already had moving away from evilvte on my radar for this new box.

Again, thanks so much for the valuable suggestions!

seth · 2025-10-22 20:57:49

it was ignoring the command line options in favor of the values set in .Xresources

Which ones exactly? (I've frankly never tested -icon and no: I doubt there's an OSC for that )

Lone_Wolf · 2025-10-22 21:07:23

barthel wrote:

Awesome! I'll put that on my wife's system now - hers is the last one to upgrade in this cycle!

Unfortunately the link came back after booting .
Investigating showed it's not only in the systemd package, but also created through tmpfiles.d .

usr/lib/tmpfiles.d/20-systemd-osc-context.conf needs to be deleted and added in another NoExtract option.

barthel · 2025-10-23 12:22:04

Lone_Wolf wrote:

barthel wrote:
Awesome! I'll put that on my wife's system now - hers is the last one to upgrade in this cycle!
Unfortunately the link came back after booting .
Investigating showed it's not only in the systemd package, but also created through tmpfiles.d .
usr/lib/tmpfiles.d/20-systemd-osc-context.conf needs to be deleted and added in another NoExtract option.

I was just about to reply that the symlink was still there - possibly because it was a symlink and not technically extracted. But you beat me to the punch!

Thanks for the extra follow-up!!

whitie · 2025-10-24 13:16:49

Only for reference: The Apache Guacamole included SSH terminal has the same problem.

Arch Linux

#1 2025-10-15 19:39:34

[SOLVED] systemd (not SSH) prepending diagnostic string to $PS1

#2 2025-10-15 20:45:25

Re: [SOLVED] systemd (not SSH) prepending diagnostic string to $PS1

#3 2025-10-16 11:29:23

Re: [SOLVED] systemd (not SSH) prepending diagnostic string to $PS1

#4 2025-10-16 14:14:30

Re: [SOLVED] systemd (not SSH) prepending diagnostic string to $PS1

#5 2025-10-16 21:07:37

Re: [SOLVED] systemd (not SSH) prepending diagnostic string to $PS1

#6 2025-10-16 21:32:43

Re: [SOLVED] systemd (not SSH) prepending diagnostic string to $PS1

#7 2025-10-17 11:49:17

Re: [SOLVED] systemd (not SSH) prepending diagnostic string to $PS1

#8 2025-10-17 12:47:35

Re: [SOLVED] systemd (not SSH) prepending diagnostic string to $PS1

#9 2025-10-18 06:40:52

Re: [SOLVED] systemd (not SSH) prepending diagnostic string to $PS1

#10 2025-10-18 08:09:26

Re: [SOLVED] systemd (not SSH) prepending diagnostic string to $PS1

#11 2025-10-21 20:09:26

Re: [SOLVED] systemd (not SSH) prepending diagnostic string to $PS1

#12 2025-10-21 20:30:53

Re: [SOLVED] systemd (not SSH) prepending diagnostic string to $PS1

#13 2025-10-22 07:25:17

Re: [SOLVED] systemd (not SSH) prepending diagnostic string to $PS1

#14 2025-10-22 14:35:24

Re: [SOLVED] systemd (not SSH) prepending diagnostic string to $PS1

#15 2025-10-22 16:21:48

Re: [SOLVED] systemd (not SSH) prepending diagnostic string to $PS1

#16 2025-10-22 18:53:21

Re: [SOLVED] systemd (not SSH) prepending diagnostic string to $PS1

#17 2025-10-22 20:16:06

Re: [SOLVED] systemd (not SSH) prepending diagnostic string to $PS1

#18 2025-10-22 20:57:49

Re: [SOLVED] systemd (not SSH) prepending diagnostic string to $PS1

#19 2025-10-22 21:07:23

Re: [SOLVED] systemd (not SSH) prepending diagnostic string to $PS1

#20 2025-10-23 12:22:04

Re: [SOLVED] systemd (not SSH) prepending diagnostic string to $PS1

#21 2025-10-24 13:16:49

Re: [SOLVED] systemd (not SSH) prepending diagnostic string to $PS1

Board footer