Yes. Just keep bash installed : )
Haha yeah, or that,
Has anybody looked into OpenBinder? There is documentation and implementation available. It has a Shell.
http://www.angryredplanet.com/~hackbod/openbinder/docs/html/BinderShellTutorial.html
Make fish the default shell
I was wondering why (Open)Binder felt Be-ish in nature - itâs from PalmSource, and ran on BeOS!
Perhaps we can adopt and extend its shell, if the source license (MPL v1.1) is compatible/usable here.
If we brought OpenBinder to Haiku, there would be some overlap with the existing system, but I think we could accomplish a lot of what has been talked about in this topicâŚ
One thing to note is that while Openbinder is MPL (which is probably incompatible for releases of Haiku as a core component, but not for applications in Depot), it was used in Android, which is Apache licensed - I wonder if that code can be brought out, or if itâs been made too Java for us.
edit - the Android binder implementation is mostly in-kernel, GPL. Itâs been upstreamed to Linux recently.
Weâd have to rewrite our own implementation of the Binder IPC API and the binder shell if we wanted to use it as a component of Haiku. On the one hand, it would be a logical continuation of the development progress of BeOS in the first place; on the other hand, it would be a massively complicated undertaking to add another IPC layer to the system at large.
Also to wit: Bash is GPL-licensed, too.
As all GUIs apt to do (regardless of OS), I do not know how many times the GUI has locked up and the user interface froze over the years. [Very common occurrence even today in all OSâesâŚ] Since I always have a terminal window open, I am able to clean up via the terminal. So the need of the text terminal allows the users to recover the system (for most occasions); as well as, interact and govern their system [if they choose to interact in this manner].
I have been thinking about thisâwhat are the âlow-hanging fruitâ or âquick winsâ that the developers can accomplish now.
My first thought is this: I do not believe we need BFS2 yet when we are not fully leveraging BFS now (IMO). An example is that I was doing some MP3 attribute adjustments in Zeta where I noticed differences in the options for the listattr, catattr, addattr, rmattr, & copyattr commands.
An example is:
Haiku version:
~> listattr --help
usage: listattr [-l|âlong] âfilenameâ [âfilenameâ âŚ]
-l, --long Shows the attribute contents as well.
Zeta version:
usage: /bin/listattr [-hmpxdcaf[format]] âfilenameâ [âfilenameâ âŚ]
-h show this help
-m ignore attributes that specify MIME-type (âMIMSâ type)
-p parseable output: no header, no multiline output (for use with e.g. awk)
-x use hexadecimal format for types and values
-d use non-friendly names for types (for developers)
-c use âclassicâ output format (resembles the old format a little)
-a use a format that can be fed back into âaddattrâ
-f change the format of the output: (default=`-f tsnvâ)
t=type
s=size
n=name
v=value
Improve these commands to better leverage the BFS attributes. Most of the previously discussed ideas could be addressed by adding extra functionality into these commands where a deificiency has been identified.
Second, if these commands were easier to be used in batch filesâparticularly where variable assignments are concerned when the output from the listattr or catattr could be more easily captured in batch scripts. For some reason, multiple calls in a script causes issues. [More testing on my part continues.]
Improve the current attribute commands we currently have in Haiku. If the commandline version is improved, the GUI version is also improved where the GUI will need to reflect these command improvements.
Third, during this discussion, we have identified the need for new SQL-like commands that can augment and report as to what listattr and catattr do nowâbut better: with enhanced seek and match to attribute values, organize/group into data values or ârecordsâ, and provide a data stream to a consumer event.
I think these three items would be a great start. What do you think?
I would prefer it to be availableânot default. bash is ubiquitous as fish is not.
However Bash isnât in the main Haiku git repo. OpenBinder shell as it is cannot be in there too, but it could still be shipped with the base system.
Ah, wondered how that worked. Yeah, I am remembering that Haikuâs buildsystem downloads those things.
OpenBinder is open source licensed. What I read in the license is that those Contributors who modify OpenBinder must include the source code. Other than that, it may be re-licensed and then the license cannot use the words Mozilla, Netscape, etc.
Am I getting this right?
Yes, OpenBinder is an IPC layer, and would be an undertaking to integrate, but then we would have a good start on what BeOS R6 was going to be!
If you develop a representative example of the problem, let us know!
Wave - new terminal design, using bash - download, click & run on Linux, so may be portable to Haiku:
A good name for a native Haiku shell :- âshellbeâ
âThe VS Code of Terminalsâ is also true for the negative side,it seems
The screenshot looks really interesting,but from a technical view I can only hope that it never gets popular.
They integrate telemetry,just like M$ does in VS Code,one of the reasons Iâd never even touch it.
A big part of it is built in Typescript,so it most likely needs Electron,a bloated Chromium beast that refuses to run on anything but Linux,MacOS and Windows (and as a Haiku/BSD/Solaris user I admit that I really love this feature,no Electron shit here )
The other big part is written in Go,one of Googles evil projects where even the compiler contains spyware/âtelemetryâ or at least they intended that: Google's Go may add telemetry reporting that's on by default ⢠The Register
Itâs surely a good decision to use that for important system applications like a Terminal that has access to basically everythingâŚ
Oh,and that terminal wants you to accept some weird terms of service,even if itâs open-source.
That again reminds me of the shady stuff Micro$oft is also doing with VS Code: Visual Studio Code is designed to fracture
My suggestion: Take inspiration from the user interface,the UX and the design they built,but donât ever touch their code and instead rewrite it in C++,without telemetry,as a native Haiku application.
A Bourne-compatible shell like bash (or zsh) is required (by definition, de jure) for POSIX compliance, particularly for scripting. But there is no sane reason it needs to be the default; it only needs to be present, so that invoking $ bash
doesnât produce Bad command or file name
.
I agree that fish is by far the superior choice and should be the default. I also believe that the best POSIX shell isnât bash, but zsh, which is now the default on Mac OS X and Kali. The only reason to include bash is to appeal to (specifically) Linux fans, since bash has become de facto the default Linux shell, but shell scripts that start with #!/bin/bash
will run fine if you change it to #!/bin/zsh
.
And I disagree strenuously with making choices to satisfy Linuxers. Donât get me wrong, I love UNIX for many or most use cases, but the dominance of Linux in the whole UNIX ecosystem is ideologically offensive to me and can/should be challenged.
In that case, you likely want zsh as default, which I can work with. zsh is a strict superset of bash, meaning itâs perfectly acceptable to set zsh as system default and then symlink /bin/bash
to /bin/zsh
. There is literally no penalty for this, because there is no feature bash supports that zsh doesnât (going the other way is a challenge, of course).
The bash shell is the default in BeOS. For this reason, it is also the default in Haiku, in order to maximize compatibility with BeOS apps and users. Linux is not involved at all in this decision, as you can see
That being said, it is an old decision, and could be revisited. But the impact on BeOS apps has to be evaluated.
Thatâs not generally true. POSIX shell scripts (that donât use any of bash extensions) will run on any POSIX compatible shells. But zsh does not always implement all of bash extensions, and bash does not implement much of zsh ones. So, scripts that are written to run with POSIX sh would work. But, often, these are tested only with bash, and ends up using bash features unintentionally (because writing strict POSIX sh compatible code is very annoying).
Is there a compelling advantage to be had by replacing bash? I mean, as I may have mentioned above, there are certainly more elegant and easier to learn shells like ârcâ, and REXX was interesting, but I donât think thatâs what weâre talking about here, weâre talking about something like bash but even more bloated.
For those who may be struggling to get something working within bashâs limitations, Iâd suggest learning how to use âawkâ. This and other simple text utilities are the context for the design of the shell. Use your tools.
We can replace it with mksh, this would have the advantage that mksh is not gpl licensed and we thus have to distribute less sources on the haiku image.
Haiku generally tries to get rid of more gpl code : )
Perhaps on 64bit we can use mksh directly.
I have no experience with zsh and other shells,but the big advantage by replacing bash with fish would be a better user experience,especially for newcomers,but it can also become useful for powerusers who get used to the extra features,like me.
I love fish for its autocomplete and history features.
Some examples:
- Type a command.If the written command is displayed in red,this binary doesnât exist,no need to try with enter.
- Start typing a command.Fish will display the most likely binary name in grey.Hit arrow right and itâs written.
- Often use ssh (or any similar command) with different servers?Start typing âsshâ,then scroll through the last used full ssh commands (with servers and options and such) by typing arrow up
- Like working with Git?Go into a directory that is part of a Git repository,now fish will also display the branch youâre currently at,next to the folder.
That being said,I canât find any disadvantage of fish,compared to bash,only advantages.And if Bash is still installed,shell scripts which specify #!/bin/bash will still get executed using Bash,even with Fish being the default system shell,so you get 100% compatibility here.