Clarification on making use of more than one shell

On leap 42.2

I believe that a different shell can be invoked in a console by simply typing it’s name and that the default shell can be restored by typing it’s name or exit. There isn’t much info about this around so wonder if this is always true or if there are complications? In my case the added shell is likely to be fish and I also assume that it would have the same level of access to the system as bash has?

The other question relates to installation. I would be inclined to use one click install from software search but have no idea if this will over ride current default shell setting or just make it available. It also seems that fish may be installed off my user directory or at least can be. So where would one be put? Might turn out not to be fish but I assume all are installed in the same manner?

Taking fish as an example the software search comes up with the supported release, newer releases and beta’s below that. I’d be inclined to go for the newest as there is a beta release and wonder if there could be repercussions?

John

On 03/19/2017 05:56 PM, ajohnw wrote:
>
> On leap 42.2
>
> I believe that a different shell can be invoked in a console by simply
> typing it’s name and that the default shell can be restored by typing

Yes; a shell is just a program. If you have rights to run it, then you
can do so just like any other program. This program happens to be a
shell, so it will accept more shell-like stuff until you exit it.

> it’s name or exit. There isn’t much info about this around so wonder if
> this is always true or if there are complications? In my case the added
> shell is likely to be fish and I also assume that it would have the same
> level of access to the system as bash has?

It should just work as you suspect. It is possible there will be
complications? Sure, just like with any program. You could also set it
as your user’s default shell, though if anything ever goes wrong with that
less-popular shell you will need to fix that on your own using another shell.

> The other question relates to installation. I would be inclined to use
> one click install from software search but have no idea if this will
> over ride current default shell setting or just make it available. It

Merely installing software should seldom change system, or even user,
defaults, and doing would likely be considered a bug in this case.

> also seems that fish may be installed off my user directory or at least
> can be. So where would one be put? Might turn out not to be fish but I
> assume all are installed in the same manner?

It would probably go in /usr/bin or /bin just like anything else if
installed system-wide. You could also put it in your user’s home
directory, sure, but that would be odd for a shell unless you were
developing and compiling it yourself. Packages typically put things like
shells in system locations, not user home directories.

> Taking fish as an example the software search comes up with the
> supported release, newer releases and beta’s below that. I’d be inclined
> to go for the newest as there is a beta release and wonder if there
> could be repercussions?

Sure; betas have bugs more-often than non-betas. Do you want a bug in
your shell? Perhaps have a system one you trust, and a beta one you can
play with should you really want to, and call the beta one when you feel
adventurous.


Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below…

Nitpicking - you return you your previous (probably, default) shell by exiting fish. When you “type its name” you start another instance of your default shell program. It is not the same. For a start, shells started when user logs into system usually behave differently (they know that they are “login shells” and set different options, process different startup files, etc). Second, each shell instance has own, independent, environment - set of variables, aliases, current directory, etc. New shell will have new environment; so if you e.g. assigned FOO=BAR in your login shell, this variable will be missing in new shell.

And to avoid misunderstanding - all of this is not specific to shell at all; it applies to every program you start. Starting any program second time creates new, completely independent, instance of this program.

There is already a lot of information to tell you that a shell is just a program and that thus calling it from a shell will simply run it until it finishes (which is most often done by typing exit).

Example:

henk@boven:~> ksh
henk@boven:/home/henk> csh
/home/henk% sh
sh-4.2$ bash
henk@boven:~> exit
exit
sh-4.2$ exit
exit
/home/henk% exit
exit
henk@boven:/home/henk> exit
henk@boven:~>

Due to the fact that all these shells show different prompts, we can see that we have here a whole stack of shells called from within shells (in proper parlance, each is a child processes of a parent process). The last one started being bash again (and, as explained above, that is a new process, a new instance of bash, there are running two of them now).
And then one after the other is finished until we are back to the original login shell (bash).

You can however also replace your shell with another one:

henk@boven:~> exec ksh
henk@boven:/home/henk> 

At first sight there is not much difference, the ksh prompt is shown. But when you now exit, you are loged out, because your original bash was replaced with a ksh process and the original bash process is not there anymore.

I thought that things would work out like that but the only info I found didn’t really point out that when another shell is activated from one for an exit to work the initial one needed to still be around. It then went on to say could also change by entering the name of another and didn’t mention what effect that would have. In other words it could finish up with bash-fish-bash rather than bash - fish going back to just bash.

I’ve read that software types sometimes prefer the csh shell. As I am one I found that surprising and that fish looks to be more suitable. Also it might turn out to be more suitable for very occasional use.

Maybe some one some day will write one that is much like other high level languages but as they are probably interpreters maybe not. I’d guess it’s a byte code interpreter, maybe word which is pretty old hat really. Even modern basics have gone past that.

John