[Solved] Nightly (feb 7) killed zsh

What’s the proper place to report this kind of issues. Open a ticket ? I updated my main Haiku PC to the latest nightly and now I can’t enter anyhing in zsh. Bash still works fine. I tried in a purely new vm and as soon as I switched to nigthlies the same thing happened.

It wasn’t happening until a few days ago so I suspect it’s something recently introduced. I saw how to switch from stable to nightlies easily and it solves the issue. Is there a way to switch to one particular nightly build and stick to it?

For issues related to packages coming from HaikuPorts… please use the following link: https://github.com/haikuports/haikuports/issues.

There has been updates to some “core” packages lately (icu, for example), so we might see more packages affected than usual until things get fully sorted out.

Edit: regarding:

Please see https://www.haiku-os.org/guides/daily-tasks/updating-system. In particular, the “Downgrading to a previous revision” section.

BTW… nice to see your username again! I remember seeing it quite frequently back in the days! :smiley:


don’t update. The nightlies are unstable, so while this revision may work for you some future ones will not.

From your messages i gathered that zsh broke, and you are on beta4? In that case indeed the proper place to report this is haikuports as BiPolar mentioned.

A “few” other packages are broken also on the latest (and long awated) bump to ICU74 on nightly, probably expected (hence nightly being testing environments), so in case you are on nightly do not update to hrev57575 untill this is fixed. Already created 2 tickets on the bugtracker, one for Falkon and on for Python, and an issue for Falkon is also reported at haikuports.

1 Like

Thanks for the pointers I’ll be reporting this on Haikuports when I get back to the machine , hopefully tomorrow (I mean today, as I forgot to post this yesterday and it was open on my computer).

I must say I am a bit lost these days as to where each part of the development happens. I coded on BeOS apps and have been following the project coming back and forgetting about it because of other “real life” issues but I always feel so happy about Haiku that I really want to get more involved and do some practical work for the community.

1 Like

So I reverted to r1~beta4_hrev57573 and zsh accepts input again so it was clearly something in r1~beta4_hrev57575 . Restoring to this nightly fighting.

I’ll report this properly in Haikuports soon.

One thing this made me think about:

The explanation here is rather simple but on first look I didn’t understand instantly that I could just run these few lines to revert to a previous nightly:

This makes me think it could be useful, especially for testers who aren’t so technical to have a tool to make this one click operation. Wouldn’t it make sense to make this easier for people who want to test on their machine on which revision something works ?

It can be a small bash script I think I can write later today. I mean something that just lists the 50 last available builds from https://eu.hpkg.haiku-os.org/haiku/master/x86_64 (or the 32 bit version) you pick one and it just reverts to that, doing a full sync and offers to reboobt.


If you are not so technical, maybe it’s better to stay on the beta release, where such things should not be needed.

To run experimental nightly build, you have to expect any kind of breakage and know your way around to fix things up when they inevitably break.

Well I wrote the script for myself to make my life easier and hopefully others’ (it’s on GitHub now). Saves a bit of typing.

But I also believe there are many intermediate levels of tech knowledge among users and each could participate.

Some may not know their way perfectly in a terminal but may have a specific hardware issues.

I believe it’s nice if devs can ask them “hey can you check if this works with current and if not check rev_h44444 and then revert back to stable”. This only makes sense if the whole process is simple — assuming the user is warned beforehand that if it goes to a point where it all crashes he has to pick the old build in boot manager and accept risks.

For many people running a terminal command (ideally just double clicking it) and making choices is doable but typing several commands correctly is a bit hard.

To be fair I considered making this even a GUI app but obviously it needs to work in most failure conditions (provided bash is still functioning ).

If the gui is broken you can’t use Haiku anyway, not even bash.

We don’t have any kernel tty layer or anything like that.

You could still use bash via ssh right ? I do it when I get display output issues. But I agree at this point we’re not talking about a complete newbie anymore.

I believe for a complete non-tech person the ideal process would be a GUI app that download and sets a hrev configuration to boot only once for testing and reverts to stable on next boot, with a big text “unstable test hrevXxx, reboot to restore stable” drawn on desktop. Not sure if this is even possible with the current system.

I have a similar ticket already.


If you want you can make a ticket for your idea (loading a development state and booting into that for testing only once.

1 Like

That’s not true at all; we definitely have a kernel TTY layer. It’d be basically impossible to implement the necessary POSIX functionality around TTYs otherwise.

I was a bit imprecise. I was reffering to the framebuffer emulation implementation that e.g linux and freebsd have to emulate a TTY on the graphics output without the app_server. ai am aware of the serial output too. But this doesn’t count as using haiku to me either.

We (sort of) have this, too, though: consoled. Debugger uses that when app_server crashes.

Yes, I patched the font once. But this isn’t intended to run applications like bash, it does not even support unicode in the font properly.

Why not? You just pipe the input and output into /dev/console.

Indeed it is currently very limited, slow, and doesn’t get a lot of attention. But this is how Haiku worked for the first 5 years or so of it existence, before app_server and interface kit would work well enough to run MiniTerminal (which we still have in test app_server) and then actual Terminal.

It’s one of the things not really on the R1 TODO list, but if someone has patches, we may well accept them.

1 Like

Because it does not (currently) work very well with such usecases.

Anyhow, I think discussing this is a bit moot?

I don’t see issues with patches improving it either.

I have managed to boot Haiku into command line, but the details are hazy now. Nevertheless, it is unsupported and doesnt provide good UX, but possible.

Edit: yes, it was using consoled.

Just want to note that I saw: https://cgit.haiku-os.org/haiku/commit/?id=bd34f534dd41ec35f41ba4ece48120e6769ef468 (which is hrev57578) looks to address the issue. I gave it a try and things are back to normal (zsh, Falkon, etc.) I suppose there could be other issues, though.


I can confirm I can now use zsh again with current. I will mark this as solved.

Edit: Hm. Is there a specific way to mark this as solved or do I just edit the title to add [Solved] ?

1 Like