I'm new to Bash scripting on Linux. Running `steamosctl get-default-desktop-session` directly in a terminal works, but running the same command from a script produces a "No such file or directory" error. The script uses `#!/bin/bash`, `set -x`, and then invokes the command. Interestingly, `steamosctl help` and `steamosctl -h` work from the script. I initially suspected that the command's hyphens were being interpreted as part of a path, and I also tried quoting the command, using its full path, and invoking it through `sh` or `exec`. The issue turned out to be related to the script's execution environment: non-interactive scripts may not inherit the same PATH and environment variables as an interactive terminal. What is the best way to diagnose and fix this reliably?
4 Answers
Since `steamosctl` may communicate with a user-session service, the command can behave differently outside an interactive desktop session. Inspect the relevant service with tools such as `busctl`, and make sure the script runs as the intended user with the required session environment. A system service may need an explicit user, working directory, PATH, and access to the user D-Bus session.
Loading `.bashrc` is not generally the best fix. Bash startup files often skip interactive-only setup when the shell is non-interactive, and `.bashrc` may contain commands that are inappropriate for scripts. Prefer setting the required PATH and variables explicitly in the script or service configuration. In this case, configuring the service with the correct user and working directory resolved the startup and terminal failures.
First check the environment available to the script. Print `PATH`, the current directory, and other relevant variables, for example with `printf '%sn' "$PATH"` and `pwd`. A script launched by a service, scheduler, or desktop startup process often has a different PATH from your terminal. Using the executable's absolute path can help, but it won't fix missing environment variables or user-session services such as D-Bus.
The hyphens are not special in this situation. Make sure you are not quoting the entire command and its arguments as one string. This is correct: `steamosctl get-default-desktop-session`; this tries to execute one command literally named `steamosctl get-default-desktop-session`: `"steamosctl get-default-desktop-session"`. Also verify that the script contains ordinary ASCII hyphens and uses Unix line endings.
That matches what I found. The problem was the missing environment setup rather than the argument syntax. Running the script through a service with the correct user and working directory fixed it.