mirror of
https://github.com/outbackdingo/hyprcosmic-session.git
synced 2026-08-25 14:53:23 +00:00
gitops
bdff38edac
PAM starts the daemon at login but brings up only its `control` socket. Nothing else brought up the rest, so a HyprCosmic session had no agent at all: SSH_AUTH_SOCK unset, every SSH operation asking for the passphrase again, and callers of the secrets API finding nothing listening. Under the stock COSMIC session the same machine works, which makes it look like a key problem rather than a session-script omission. `--start` attaches to the daemon that is already running and brings up the missing components; on this machine that created `pkcs11` and `ssh` alongside the existing `control`. Where the socket path comes from is the part worth writing down. start-cosmic evals the daemon's stdout, but the eval is `eval "$(... > /dev/null 2>&1)"` -- the redirect is inside the substitution, so it always evaluates the empty string, and the block works only because of the socket checks after it. Rather than repair that by evaluating whatever a daemon writes to stdout, this reads out the single variable we want and keeps the fixed paths as the fallback. The daemon also writes chatter to stderr, so the 2>/dev/null is load-bearing for the parse rather than tidiness. start-cosmic's rule is kept intact: set the correct socket or set none at all, never a wrong one. A plain file sitting where the socket belongs is rejected by the `-S` test, and a machine with no keyring directory skips the block entirely. SSH_AUTH_SOCK then joins the systemd and D-Bus activation environments for the same reason XDG_CURRENT_DESKTOP did: a user unit or an activated app looks there, not in this script's environment. `import-environment` ignores an unset name and exits 0, so a machine without a keyring still logs in.