Not just #!/bin/bash, #!/bin/sh also should continue to work the same. Which although executed by the same bash, follows slightly different POSIX specification. For example, “. xyz” where there isn’t an xyz, will abort the script, where when running as bash the script continues anyway. All this seems to me to be working fine as it is, and really perilously complex to change.
The user shell is a different matter, one where likely there’s no one shell that suits all. I haven’t gone there, as I’m reasonably happy to use bash, so I’m unclear how one may choose the user shell. I’m surprised to see no Terminal option.
It’s functionally just an interpreter, so if you type fish or zsh and ENTER you will be in that shell until you type exit.
Scripts that need the other shell should start with #!/bin/zsh
or #!/bin/fish
Same as python or perl, really.
Setting the default shell should be possible in a configuration file somewhere. Perhaps an opportunity for someone to write a little Preference applet?
#! /bin/sh
# ShellChoice.sh
# Open up a Terminal with your choice of shell
# Will run from a Terminal, or you can compile it with shc:
# shc -o ShellChoice -f ShellChoice.sh
# and move the executable to /boot/home/config/non-packaged/data/deskbar/menu/Applications
# Requires hdialog
if ! [ -e /bin/hdialog ] ; then
installhdialog=$(alert "Required utility hdialog not found! Install it?" Yes No)
if [ $installhdialog = Yes ] ; then
/boot/system/apps/Terminal pkgman install hdialog
else
exit 1
fi
fi
# Let's see what we've got
shellcollection=bash
if [ -e /bin/dash ] ; then shellcollection="$shellcollection dash" ; fi
if [ -e /bin/es ] ; then shellcollection="$shellcollection es" ; fi
if [ -e /bin/fish ] ; then shellcollection="$shellcollection fish"; fi
if [ -e /bin/mksh ] ; then shellcollection="$shellcollection mksh" ; fi
if [ -e /bin/xonsh ] ; then shellcollection="$shellcollection xonsh" ; fi
if [ -e /bin/zsh ] ; then shellcollection="$shellcollection zsh" ; fi
# Exit if no alternative shells are present
if [ "$shellcollection" = bash ] ; then
alert "No alternative shells found! Please install at least one shell besides bash." OK
exit 1
fi
shellcollection="$shellcollection EXIT"
shellchoice=$(hdialog --radio "Open Terminal with which shell?" $shellcollection)
# Exit if requested
if [ $shellchoice = EXIT ] ; then
exit 0
fi
# actually do it now
export SHELL=/bin/$shellchoice
/boot/system/apps/Terminal /bin/$shellchoice &
exit 0
I wonder how hard that would be to implement as a combobox… radio buttons really aren’t the right choice for that because it makes the vertical height of the window dependent on the number of shells.
Maybe its good enough… but then that is why everyone still uses bash.
Not sure why you think that, Haiku doesn’t distribute bash sources in the image, they can be distributed separately… its a non issue. Pretty much all of Haiku’s MIT sources even comply with GPL type requirements above and beyond the MIT license… because it just makes sense you just aren’t “forced” to.
It would probably be handy if it were built into Terminal. Being able to set the default shell in its options. Maybe even have a “Open New window/tab Using…” so you can open a new session with a different shell.
That is option a). Please see option’s b and c good grief did you even read the license before you replied to me in such an authoritative tone?
b) Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,
c) Accompany it with the information you received as to the offer to distribute corresponding source code. (This alternative is allowed only for noncommercial distribution and only if you received the program in object code or executable form with such an offer, in accord with Subsection b above.)
Literally all you have to do to comply is include a link to the source in the about screen and, keep it hosted for 3 years. Bundling source is just an easy way to do it… if you want to avoid the downloads of that or reduce image size that is a separate issue.
On the images you download from the website, it is a non-issue.
On the DVDs we distribute (when we do physical DVDs), it is a bit more complicated. It’s possible to do it in a way that you don’t redistribute the sources alongside the binaries, but you need to also give a written offer to provide the sources in that case. This would make it more complicated than needed for people to just pass around these DVDs without thinking about it.
The paperwork and what you’re allowed to do is also a bit different between GPL v2 and v3, and if you distribute “GPL v2 or later” software, you basically need to do it in a way (or multiple ways) that complies to the requirements of both licenses.
So, to avoid any questions, we just put the sources in the DVD. Then it is very clear that there are no problems, and you can give the DVDs to anyone without any risk of getting into legal trouble.
Since you quote the relevant clauses:
Option C is not available for us, since we don’t want to be restricted to noncommercial options
Option B would require anyone who distributes a binary DVD to also offer either a source DVD or a download link to the sourcecode. The download link is not necessarily clear, the way this is worded (“on a medium customarily used for software interchange”) may not include “just download it from the internet”. Also, it’s not clear if you can say “just download it from someone else’s server”, which is what anyone redistributing these DVDs would be doing. Also, does the 3 year timer start from when the DVD is pressed, or when someone re-distributes it? Or are people forced to use “option c”?
Also, imagine if someone asks us for the exact sources from 3 years ago. We would be unable to provide them now. Part of it is in Haiku git repository and we could find it. But the exact sources for everything else? Good luck with that, since haikuports has no tag and Haiku images are not even built from a consistent set of haikuports packages coming from the exact same haikuports commit.
And that’s just one version of the license. The other version has slightly different clauses… And soon you find yourself saying “I’m not sure anymore, we should ask a lawyer about all these questions”. Which is not worth the cost of it, of course.
From experience with GPLv2 (I am not a lawyer, I am not your lawyer, I am definitely not HINC’s lawyer, and this is from the persepctive of US copyright law):
The timer starts at the first point which a third party receives a copy of the new binary object code. Whether that is through download or by way of a sale or handing-over of physical media.
Such “a medium customarily used for software interchange” refers typically to the same medium by which you distributed the software in question, but may differ, as long as the media aren’t obscure, proprietary, or difficult to obtain the source code from. (e.g., no tapes, unless the software itself is primarily distributed on tape.)
Today, I’d say USB flash media, SD cards (microSD, in an SD adapter) and USB external drives are probably more acceptable than optical media for this purpose.
The internet does count as such a medium, but the hosting must be from the first-party and be online for three years minimum.
(These are opinions, not facts, and not legal advice.)
Pretty much everything you said are stipulations on top of GPL whatever version… that don’t exist in the text… so they really carry no weight unless some case law somewhere has decided that way.
As an example. At this point probably certainly over 50% of GPL software is NOT hosted first party but is hosted 3rd party… nothing in the GPL states that making it available must be carried out by a first party alone.
A native shell would be good to have, and a shell selector too. And then there’s the never-ending problem of which is better CLI or GUI.
But an app called “olivetin” is interesting, because it’s kind of a middle solution. It’s not fully CLI terminal, and not fully GUI. Instead, it’s a web app that uses a browser to display buttons (with pictures) that can represent commands or scripts. It also has sub-menu’s for the buttons. It makes it easy for ppl to learn to use commands. Its a great idea - and may be even better if it was a desktop app with buttons for all the shell commands. It’s written in GO and YAML.
If you had this app in an OS it could become popular with students and teachers. And if you could get Haiku into schools as a fun way to learn computing - it would be a great source of users (& future developers). That’s what Microsoft did - but it wasn’t much fun no doubt.
Thoughts on educational potential? Possible to port it?
I don‘t mind educational software, but this as a learning tool for shells seems very strange to me, mainly because buttons are a very leaky abstraction for the shell. It may work for single cases, but how would it teach you about the shell? There are so many things you can do wrong accidentally on it :g
Possibly interesting, to the extent the use case is real - give your family these buttons? More generally, computer admin uses this easy tool to for use by less sophisticated users. Is that a thing here, are there a lot of Haiku admins serving up access to the less sophisticated?
My design perspective is that the people who would use this, need to be reasonably well versed in sh, and it would be possible to eliminate the yet-another-language aspect by driving a graphic interface from a shell script via messages. That wouldn’t have to be as cumbersome as hey.
The examples make it look so simple, you just put a button up and presto, you can use it execute some ssh command that restarts a server or whatever. But what do you want to do with errors? Your user is probably here because something went wrong, so obviously it’s important to consider this. How do you get errors back from a command issued via ssh? Can you do some analysis on the errors? These are things you can do in the shell, which is where you need to be setting the thing up.
(That’s about the concept as presented on its web page. As a sort of graphic version of the shell – I just don’t see it, at all. The command line isn’t just a set of command names to select from. Each command has a potentially somewhat complex set of parameters and flags, and trying to represent that in buttons doesn’t seem like it’s going to cause much excitement. I mean, sure, there are ways to think about doing that, but it’s a gigantic task that doesn’t really have much to do with a graphic wrapper.)
