Issues running zsh

When using Haiku I prefer having my shell setup in a similar fashion as on other operating systems. Thus I have selected /bin/zsh as my shell. Unfortunately this does not come without issues. One being #18612, which obviously is well known, and fixed although not merged. Two other issues are seen whenever launch a new shell with these two errors:

/packages/zsh-5.8.1-6/.settings/zsh/zshenv:[:2: too many arguments

ERROR: this script is obsolete, please see git-completion.zsh

The first is incorrectly assuming a user might only have one or zero out of a set of possible zsh related configuration files in their home directory, the cause of the second one is unknown to me.

While I could file two issues and attempt to suggest their solutions, I figure it to be best asking here first. The main reason being that I casually dropped the second error message on irc a while ago and saw a reply saying that it was known and possibly also already patched. However I find nothing seemingly related when searching. Even if the Bug Tracker Etiquette does not specifically mention to avoid posting duplicates, I figure asking here is better than risking to do that.

Are there issues for these two bugs which I fail to find? or would some facts be considered known in the Haiku community and be tracked somewhere else? or might this just perhaps have been a case of something encountered frequently enough to be remembered, but maybe not actually having a ticket?

Not sure about the other issues, but the first you mention as

fixed although not merged

The fix was actually merged in hrev57310.

You might just have an older version of the default /etc/profile, and will need to fix it manually.

AFAIK, settings files under /system/etc/ are never automatically updated (nor old files removed) with newer versions of packages. That can cause hard to debug problems.

Examples:


FWIW, I installed zsh on a pretty clean beta5 32 bits install, started zsh, and I don’t see any error message.


Maybe we should have some PSA type of posts here on the forum at least for when that kind of settings-related breakages inevitably occur.

2 Likes

This bug is only triggered if you’re storing your dotfiles in ~. You should consider moving your zsh init files to ~/config/settings/zsh. In any case, the problem should be fixed with zsh-5.8.1-8 but it will require you to manually copy the new zshenv file since you already have an existing one.

cp /system/packages/administrative/writable-files/zsh-5.8.1-8/settings/zsh/zshenv /system/settings/zsh/zshenv
2 Likes

Thank you @BiPolar and @Lrrr! Even if I might say I’m both surprised and a bit disappointed by Haiku’s behaviour regarding system config files, I’m most appreciative of your very helpful answers!

Haiku’s non-standard config file placement is my key learning from yesterday. I spent way too much time on attempting to move and modify config files, including those which in the end had to remain in their ~/.-locations to actually function.

Yey! That one led to great success!

Ah! That’s how to properly read that. I did see the merge, but understood it as presumably only being on a the master branch until a Milestone got Scheduled to cherry-pick the fix into an actual release branch. I even managed to convince myself that was the case when quickly looking at the git graph. It’s funny how the brain can be this good at tricking itself.

After deinstalling and reinstalling zsh, I took the liberty of bolding a word in the above quoted text. Manually copying the file from a git checkout did the trick. Unlike zshenv, the profile file was not to be found under /s…/p…/administrative or any other path on in my entire filesystem.

The obsoletion message came from settings/etc/profile.d/git-completion.sh +3602 of /b…/s…/p…/a…/w…/git-2.42.0-2/. Later versions of git completely lacks the file. After removing it from /etc/settings it got my shell to start without any warnings.

That seems like a good thing to have. I sure did search before posting. Guess the tricky part is to find someone to volounteer to make such posts whenever needed, and to some degree even knowing which breakage that requires to specifically be addressed. Maybe time is better spent explaining it once someone actually encounters problems. I sure am thankful for the support in this thread!