Why do you feel it is harder in Windows? In Windows 11, go into the Settings app, search for 'Path', then choose "Edit environment variables <in system/in account>". You then get a graphical method to add/edit/delete entries, and the paths apply to any application you run. No need to find a dotfile to edit. No need to know how to format a particular entry, or chain it with the existing $PATH.
On macOS it is arguably harder as you need to use Cmd-Shift-. to reveal dotfiles should you be uncomfortable editing them with vim/nano/etc. When using Omz with Terminal, a path entry could be in any number of files supporting Omz along with my zshrc. Windows doesn't have this issue.
Windows has it's issues, but env vars are significantly easier to manipulate without much knowledge.
The problem is that Linux does not have solid way of setting environment variables for an user (or user session). .bashrc is relevant for only bash (obviously), but bash is not the only thing that needs PATH and other env vars.
At least systemd brought some sanity with environment.d, but as this thread (and jvns article) shows it's not very well known. And of course there is still all sorts of weird inherited complexity like pam_env.
The Windows has a system-wide variables (incl. PATH) applicable everywhere. In contrast, the Linux situation is touched in the submitted article.
>All of these directions only work if you’re running the program from your shell. If you’re running the program from an IDE, from a GUI, in a cron job, or some other way, you’ll need to add the directory to your PATH in a different way, and the exact details might depend on the situation.
>I’m honestly not sure how to handle it in an IDE/GUI because I haven’t run into that in a long time, will add directions here if someone points me in the right direction.
The ~/.pam_environment was the equivalent to Windows' environment variables but has been deprecated and supposedly systemd's environment.d took over its functionality.
I don't know what she means about setting the PATH for a GUI. If you want to run a program from the GUI you add a .desktop file to ~/.local/share/applications and provide the full path to the binary as part of the Exec key[0]
You can also override the actual PATH variable for an application in the .desktop file as well, or any environment variable, with the Environment key, if that's what she means.
Tbh the moment you need to use a terminal is the moment you're googling the magic spell unless you've previously googled the magic spell.
On Windows you just go Win->start typing "environment variable" and you get "Edit the system environment variables - Control Panel". Kinda stupid that you then need to press "Environment Variables..." but I probably wouldn't have to google it.
The difference on Linux/BSD/macOS is that the Window Server is a userland application -- you can't depend on it existing (except macOS), nor can you depend on the underlying shell being consistent on a given OS/distribution (macOS ships with a deprecated bash shell and current zsh shell).
On Windows, Microsoft has it easy. The window server is part of the executive; Win32/conhost always exist, even if you choose to run another personality (OS/2, POSIX, et. al.).
I would bet that there is a form of graphical editor somewhere out there on the Internet that someone developed for fun for a given shell.
It's improved since then though. When you edit the PATH variable it presents a list of items you can edit and reorder rather than one long delimited string
