ZSH Path Source Location and Execution of a zsh script

This is because you have the path added somewhere in between.

I made the same mistake at some point - cannot quite remember - but I think it was my local .profile which.

Manjaro zsh profile has changed to be fetched from /usr/share/zsh/ where manjaro-zsh-config and manjaro-zsh-prompt is located.

The file from /etc/skel/.zshrc - is sourcing the mentioned files - if they exist.

1 Like

I’ve done several text searches just for /home/gerald/.local/bin. It returns only one place. The bash file that’s located in /etc/profile.d. I’ve found no commands as in your example of profile such as append_path ‘/usr/local/sbin’ and bin and 'usr/bin". So, the location the current path including the duplicates is still a mystery to me. I’ve got an updated Gnome from 19 I believe. Its bash and the path structure looks to be exactly the same. I briefly looked around could not find the path source either. The home bin directory was called by a bash script as well.

The only file that has the paths is man_db.conf. I could be wrong but it does not appear that its being used to set the path.

That maybe true, but when I use “dash” insted of “bash” that acts like POSIX "sh"ell.

My system get’s faster. :3

And I bet dash is closer to pure posixness :smiley:

EDIT: will switch to zsh as well, you all hyped me! thx

Try the literate search ‘$HOME/.local/bin’ because this would be more common for scripts as they - unless created by the user - never know which user is actually running the script - and therefore uses the environment variable $HOME.

My environment reflect that I use nvm to manage/run a local node.js server - but when I remove that - it looks pretty default

➜  ~ echo $PATH
/home/fh/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl

As the ~/.local/bin is sourced from /etc/profiles.d/home-local-bin.sh you should remove the entry from your local files - as adding it there will result in duplicate entries.

1 Like

The problem with duplicate entries for the home path was it being executed twice. I commented out the command and both entries disappeared. I had duplicate entries for the perl paths as well.

The duplicate home path happened when I created the bin directory as described in the original path. I understand now how the custom paths work in profile.d. The default paths /usr/local/bin:/usr/local/sbin:/usr/bin are in etc/profile file.

So, last night I formatted the drive and installed the OS again. Its back up and running with the paths correct. Thanks for all the help. I really appreciate it.

News to me! Now it makes me wonder why more Linux OSes aren’t using zsh for login.

Completely unrelated to your problem...

I still use zsh as user shell on my system. I have six separate scripts between root and I which changes the appearance of root when I sudo into it and after lots of paste I managed to make a config which works using “Global” settings which are applied to all users with per-user modifications, using Powerlevel10K as theme without shell managers like antigen and oh-my-zsh. Pretty dope stuff honestly.

1 Like

Yes. Me too. Here’s the article on it. Ran into it trying to find a resolution to my problem of duplicate paths. I noticed when I logged in as root that its bash. I’m already a bit spoiled with the terminal in ZSH. When I was logged into the root account I was expecting the same behavior. Didn’t realize I had become used to it in two days. Several forums covered the duplicate entries issue but no permanent fix. Still not going to stop searching until I find an answer. But I’ve exhausted all the usual places over two days.

Thank you for all the help. Yes I have this file on the new install. Probably missed it on the old install. Just too tired trying to find the problem. So now I have a pretty good idea how the path is created. The ‘profile’ in etc directory takes care of the default entries. The profile.d takes care of the rest via the scripts. I disabled the script that creates the path for the bin directory in home. That deleted both entries in the path. So it appears that the script is being executed twice creating the double entries. The double entry being created by me adding the bin directory as per the path. Not sure why it would do it in the first place. Deleted the bin directory does not reverse the double entry. I won’t be doing that again. So, that’s why I decided to just format and install. I’ve got 7 distros on my test machine. But you don’t learn much doing that at the beginning. I don’t have enough knowledge as to find how its being executed twice. On my new install I disabled the home local entry by commenting out the code that creates the home local path first boot.

I checked Ubuntu and they have a script that only creates the path entry if the bin directory exists. The entire default path is in etc/environment.

Also interesting that the root account is using bash not zsh.

Apple’s switch to ZSH was more about licensing than anything else. They were stuck on BASH v3.2 which was released in 2006. Because with bash 4.0 the licensing switched over to GPLv3 which isn’t a license most companies can live with. So they have had to maintain bash on their own providing their own security fixes, etc over the years and it has mostly just reached a point where switching shells was more beneficial than trying to keep the version of bash from 2006 working and secure.

As for why distributions don’t switch to zsh vs bash for login it really isn’t needed. Where ZSH shines is in the interactive use, from a script standpoint you don’t need the bells and whistles like command completion. For the most part BASH is universal no matter what distribution you are using so if you write a script in bash it is most likely going to work on any system you use it on whereas zsh is only going to work on systems that people have installed zsh on it.

Just found out that during the install of Ubuntu 20.10 that a choice of installing ZSH is listed. I believe it was on 20.04 but listed as experimental. I was not aware that Apples choice was more about licensing than technical.

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.