[solved] bash: systemd_osc_context_cmd_id: unbound variable

stefan · 2025-11-07 09:10:01

Hello!

I've done an update after a lengthy absence (5 weeks). I'm observing two effects that may or may not be related. I'll post as two different issues, so that they can be closed individually.

The other issue is agetty extra text: "Try contacting this VM's SSH server..."

In text mode (i.e., without running X) every command I type into bash is first answered with `systemd_osc_context_cmd_id: unbound variable`:

foo@bar:~$ true
-bash: systemd_osc_context_cmd_id: unbound variable

This seems not to be related to the prompt configuration I use, since
canges to `$PS1` and `$PROMPT_COMMAND` show no effect:

foo@bar:~$ PS1='$ '
-bash: systemd_osc_context_cmd_id: unbound variable
$ unset PROMPT_COMMAND
-bash: systemd_osc_context_cmd_id: unbound variable
$ true
-bash: systemd_osc_context_cmd_id: unbound variable
$ set +u
-bash: systemd_osc_context_cmd_id: unbound variable
$ true
$          # Note: error is gone

I intentionally have `set -u` in my `/etc/bash.bashrc` in order to snoop out sloppy shell code. I assume this to be the case here, but I do not know what piece of code triggers this.

This does not show up in a bash running in an xterm of a X session, though.

Further info:

$ systemctl --version
systemd 258 (258.1-1-arch)
+PAM +AUDIT -SELINUX +APPARMOR -IMA +IPE +SMACK +SECCOMP +GCRYPT +GNUTLS +OPENSSL +ACL +BLKID +CURL +ELFUTILS +FIDO2 +IDN2 -IDN +IPTC +KMOD +LIBCRYPTSETUP +LIBCRYPTSETUP_PLUGINS +LIBFDISK +PCRE2 +PWQUALITY +P11KIT +QRENCODE +TPM2 +BZIP2 +LZ4 +XZ +ZLIB +ZSTD +BPF_FRAMEWORK +BTF +XKBCOMMON +UTMP -SYSVINIT +LIBARCHIVE

`systemctl status` reports `Running`, everything seems fine.

Last edited by stefan (2025-11-08 16:59:42)

seth · 2025-11-07 13:59:34

https://bbs.archlinux.org/viewtopic.php … 3#p2268943 ?

stefan · 2025-11-07 16:07:20

What the ☠#☣@?

I stopped not liking Pickering some time ago. I managed to approach (not: achieve) "not give a f***". I am relapsing.

But franky, I don't quite get it. What does this do? Why? And how? And why is `bash` affected?

seth · 2025-11-07 18:38:39

Lennart's gonna lennart…

It's gonna be sourced by your login shell and then you're probably running into this code path?
https://github.com/systemd/systemd/blob … ext.sh#L63

It's tagging the login shell with a random UUID - why?
Lennart's gonna lennart…

stefan · 2025-11-08 10:22:05

I just find the attitude of these guys unbearable.

Anyways, I've promoted this upstream:
https://github.com/systemd/systemd/issues/39639

seth · 2025-11-08 13:05:07

Did you track the invocation (wrap that scriplet in "set -x" / "set +x")?
This isn't exactly like the other thread where the TE could not make use of the self-invented OSC, but unconditional access to a variable (which does seem like a clear cut bug on systemd's side) but it'll likely help them to know how you're ending up there.

stefan · 2025-11-08 16:59:24

I’ve never liked /etc/profile.d basically providing a means where every package can add stuff to my environment. I have now removed scanning /etc/profile.d and rather source things explicitly instead.

Digression

Quite some time ago I was annoyed by the structure of the bashrc and profile files, and how that structure did interact with my habits (which may be debatable, agreed). I have thus restructured them to basically look like these as a starting point:

$ cat /etc/profile
PATH="/usr/local/bin:/usr/bin:/bin"
test -d "${HOME}/.local/bin" && PATH="${HOME}/.local/bin:${PATH}"
export PATH
# before today: source all from /etc/profile.d/
source /etc/profile.d/locale.sh
if test "${PS1+x}"; then source /etc/bash.bashrc || true; fi

$ cat /etc/bash.bashrc
set -u +H -C
shopt -s checkwinsize failglob globstar

For the user’s local files, its based on these:

$ cat .profile
test -z "${DISPLAY:-}" -a "$((${XDG_VTNR:-0} % 2))" -eq 1 && exec startx
if test "${PS1+x}"; then source ~/.bashrc || true; fi

$ cat .bashrc

From there’ I’ve added stuff I find convenient, but too embarassing to share here now ;-) so I’ve omitted it, especially from ~/.bashrc which appears empty above.

Note the last line in each of the profile files: If $PS1 is set, then the respective bashrc file is read, because bash would not do this for interactive shells. This is a very simple setup that has served me well in the past. The only thing I’ve changed today is removing the automatic inclusion of everything in /etc/profile.d (which I had kept from the original, against my reservations).

Of course, things may break things will break doing it this way, e.g., the locale settings were broken until I added the respective line back to /etc/profile. But this approach (add what you miss) seems to give me more peace of mind. YMMV.

For new additions to these files, there are two questions to answer: (1) Stuff for interactive shell sessions goes to one of the bashrc files, stuff for an entire session goes into one of the profile files. (2) Private stuff goes to $HOME, while shared settings go to /etc/.

I don’t know whether /etc/profile.d/ is standardised in any way, if it can be expected to exist on every Linux system, or if this is a Arch decision. But I am sceptical to this “everything automatically” approach. The user (IMNSHO) should be aware of the changes that a package applies to the system. And packages should (also IMNSHO) refrain from just adding stuff to every shell invocation the user did not explicitly ask for.

I, personally would really prefer to have a package’s documentation tell me what makes sense to add to my environment, rather than just adding something without informing me.

Last edited by stefan (2025-11-08 20:38:03)

Scimmia · 2025-11-08 17:03:00

You're also going to break perl, debuginfo, and any number of other things doing that. Terrible idea.

seth · 2025-11-08 20:27:08

I find convenient, but too embarassing to share here now ;-)

seth wrote:

Did you track the invocation (wrap that scriplet in "set -x" / "set +x")?

I don’t know whether /etc/profile.d/ is standardised in any way

It's a common pattern across distros since at least the 90ies - stuff will rely on it so you should™ not disable it's general invocation but just block the stuff you don't want to see there.

stefan · 2025-11-08 20:36:57

Assuming you refer to skipping `/etc/profile.d`, not the restructuring of the bashrc and profile files:

Scimmia wrote:

You're also going to break perl, debuginfo, and any number of other things doing that. Terrible idea.

Yes, maybe that approach is a bit blunt.

But frankly, for most things I see there, I don't know what they are for. Yes, I'm fully aware of the blatant ignorance oozing from that statement. If I killed something important, then I hope it manifests in a way I'll recognise. I'll highlight the "things may break" in my previous statement.

But the only alternative I see is to remove `80-systemd-osc-context.sh` and to set up tooling that makes sure it is not recreated. Basically setting up part of the system to fight another part. That just feels revolting.

stefan · 2025-11-08 20:41:58

seth wrote:

It's a common pattern across distros since at least the 90ies - stuff will rely on it so you should™ not disable it's general invocation but just block the stuff you don't want to see there.

Sorry, was editing simultaneously. Hmmmm. I'll reconsider this depending on the pain it causes.

The most concerning prospect is that I may show up in this forum with a stupid question caused by having it my way today... m(

Last edited by stefan (2025-11-08 20:43:20)

seth · 2025-11-08 20:52:20

Brute force painless solution:

echo '# gfy lennart' | sudo tee /etc/profile.d/80-systemd-osc-context.sh
sudo chattr +i /etc/profile.d/80-systemd-osc-context.sh

[Edit: to be clear - it's always fun to tell lennart to gfh, but this might just expose a problem with the surrounding shell code.
We *know* it's violently jamming an OSC into the shell w/o consulting the terminfo, but that's *not* your situation. You should™ not see this.
I however also suspect that this is simply a bug w/ the last code path in the scriptlet]

The most concerning prospect is that I may show up in this forum with a stupid question caused by having it my way today...

There're no stupid question except for those you're supposed to already know the answer for and he that breaks a thing to find out what it is might have left the path of wisdom, but he sure also figured how it works when repairing it

Last edited by seth (2025-11-08 20:56:33)

Arch Linux

#1 2025-11-07 09:10:01

[solved] bash: systemd_osc_context_cmd_id: unbound variable

#2 2025-11-07 13:59:34

Re: [solved] bash: systemd_osc_context_cmd_id: unbound variable

#3 2025-11-07 16:07:20

Re: [solved] bash: systemd_osc_context_cmd_id: unbound variable

#4 2025-11-07 18:38:39

Re: [solved] bash: systemd_osc_context_cmd_id: unbound variable

#5 2025-11-08 10:22:05

Re: [solved] bash: systemd_osc_context_cmd_id: unbound variable

#6 2025-11-08 13:05:07

Re: [solved] bash: systemd_osc_context_cmd_id: unbound variable

#7 2025-11-08 16:59:24

Re: [solved] bash: systemd_osc_context_cmd_id: unbound variable

Digression

#8 2025-11-08 17:03:00

Re: [solved] bash: systemd_osc_context_cmd_id: unbound variable

#9 2025-11-08 20:27:08

Re: [solved] bash: systemd_osc_context_cmd_id: unbound variable

#10 2025-11-08 20:36:57

Re: [solved] bash: systemd_osc_context_cmd_id: unbound variable

#11 2025-11-08 20:41:58

Re: [solved] bash: systemd_osc_context_cmd_id: unbound variable

#12 2025-11-08 20:52:20

Re: [solved] bash: systemd_osc_context_cmd_id: unbound variable

Board footer