An article like this would be better if it didn't gloss over the different bash startup files and when they get loaded.<p>Many times when I help someone debug their shell, the root cause is not understanding what each of those files is for.<p>Adding an echo to the wrong one and not having it check if the shell is interactive can break all sorts of things like scp for example. And in weird and non-obvious ways.
When I was going back and forth between bash and zsh more, I started keeping a ~/.commonrc file that uses only some subset of syntax that's compatible with both, and sourcing that file from both .bashrc + .zshrc .<p>Things like adding to the PATH, aliases (well, ones that work in both bash and zsh), shell functions, etc, can just go in .commonrc and be forgotten. It's nice.
Step 1: echo $SHELL
Step 2: should mention profiles
Step 3: is likely confused by terminal emulators that do not start login shells so profile is not reread (this is also why you don’t have dozens of duplicate path entries all the time). Trial and error is misleading without knowing why login items are or are not reread.
Step 4: adding these statements to rc’s will generally lead to duplicate entries for nested shells
Step 5: starts nested shells, so prior instances of step 4 demonstrate the problem with step 4. A login shell can generally be started cleanly like exec env -I $SHELL -l<p>Problem 2: comes from an all too common choice not to understand profiles and login shells. This includes vscodes choices.<p>Problem X: adding empty string to your path. This has all kinds of bad outcomes.
There's room for an equally incredibly helpful illustration of how over complicated with edge cases it can be to add directories to your Windows PATH (and set initial shell start commands).<p>I deal with both command.com and bash on a regular basis and both have odd scope gotcha's .. Windows has the Admin | current user split and options for affecting session shells or all future shells, and two(?) potential registry entries and|or environment strings.
I really like the /etc/paths.d/ mechanism the mac uses. Such a simple thing, I'm surprised I haven't seen it adopted elsewhere.
Ah yes, an article which is both incredibly helpful and illustrates the absurdity of how over complicated it is to do something simple like adding a directory to your PATH.