What the shell? Bash, KornShell & zsh

Steve · 2017-11-08 07:14:23

Head_on_a_Stick wrote:

Side question: why are you so hung up on DBus?
I think you will find that systemd is almost obsessive about launching sessions for anything with a pulse so perhaps try removing all that stuff?

Those scripts came with the distro im using which is using openrc not systemd. Its an arch spin, i should have mentioned this sorry. Archbang https://distrowatch.com/table.php?distribution=archbang

Thanks for that other info.

Steve · 2017-11-08 07:18:44

Head_on_a_Stick wrote:

Actually, this reminds me...
Steve wrote:
im on arch linux, Ive just chsh to mksh
If you have the time, could you please check if this bug applies to your system:
https://bugs.archlinux.org/task/55053?p … tring=mksh
tl;dr: running `pkexec gparted` will throw an error unless a /usr/bin/mksh line is added to /etc/shells.
Also, my mksh AUR packages include a statically-linked version (using musl libc rather than the bloated GNU C libraries) which you may be interested in:
https://aur.archlinux.org/packages/?O=0&K=mksh

I installed this arch package https://www.archlinux.org/packages/comm … 6_64/mksh/

And yes this bug applies.

sc@#!:~ $ pkexec gparted                                                                 
The value for the SHELL variable was not found the /etc/shells file

This incident has been reported.
127|sc@#!:~ $

Head_on_a_Stick · 2017-11-08 07:27:52

johnraff wrote:

I am left wondering, though, why most of the major systems - including Arch - are still using bash as the default user shell.

Yes, me too

In respect of Arch, they like to stick with the upstream defaults so it makes sense for them to choose bash.

Anyway, Android use KornShell (mksh specifically) rather than bash and that operating system is _much_ more security focused than GNU/Linux.

Surely they have some pretty security-conscious devs thinking about these things?

Maybe they left to use OpenBSD ]:D

I very seldom use the full bash functionality on the terminal, however - mainly the { } syntax, tab completion, and history parsing. Do they also work on ksh?

{} works fine (if you mean functions?) as does tab completion, although I haven't found out how to make it case-insensitive (yet).

I don't use a HISTFILE with KornShell but it is possible to set one up, I think.

Anyway, the best fully-featured interactive shell is zsh, the extended globbing is so good that you don't need a file manager 8)

I am prepared to sacrifice some of zsh's awesome convenience for KornShell's speed and simplicity.

Steve · 2017-11-08 07:32:57

Is it just a matter of putting /usr/bin/mksh into etc/shells file as per below?

#
# /etc/shells
#

/bin/sh
/bin/bash
/usr/bin/mksh
# End of file
/usr/bin/git-shell
/bin/mksh

Head_on_a_Stick · 2017-11-08 07:34:53

Steve wrote:

Those scripts came with the distro im using which is using openrc not systemd

Ah yes, I see.

Do ArchBang not have a dbus script in /etc/init.d/?

That's how Alpine manage it under OpenRC and I have a hard time turning the little bugger off.

yes this bug applies

Thanks, that's reassuring, shame you can't add to the bug report — Alad would get mad if he found out you were running ArchBang.

Head_on_a_Stick · 2017-11-08 07:36:39

Steve wrote:

Is it just a matter of putting /usr/bin/mksh into etc/shells file as per below?

Yes, just so.

Because it is a packaging bug you will have to remember to remove the line if you ever remove the package.

Alternatively, try one of my AUR mksh versions, they are packaged correctly and will manage /etc/shells for you O:)

Steve · 2017-11-08 07:40:24

Seems like there is an init.d script there.

sc@#!:~ $ cat /etc/init.d/dbus                                                           
#!/usr/bin/openrc-run
# Copyright 1999-2016 Gentoo Foundation
# Distributed under the terms of the GNU General Public License, v2 or later

extra_started_commands="reload"

description="An IPC message bus daemon"
pidfile="/run/dbus/pid"
command="/usr/bin/dbus-daemon"
command_args="--system"

dbus_socket="/run/dbus/system_bus_socket"

depend() {
	need localmount
	after bootmisc
}

start_pre() {
	/usr/bin/dbus-uuidgen --ensure=/etc/machine-id

	# We need to test if /run/dbus exists, since script will fail if it does not
	checkpath -q -d /run/dbus 
}

stop_post() {
	[ ! -S "${dbus_socket}" ] || rm -f "${dbus_socket}"
}

reload() {
	ebegin "Reloading D-BUS messagebus config"
	/usr/bin/dbus-send --print-reply --system --type=method_call \
			--dest=org.freedesktop.DBus \
			/ org.freedesktop.DBus.ReloadConfig > /dev/null
	eend $?
}

Steve · 2017-11-08 07:44:41

Head_on_a_Stick wrote:

Steve wrote:
Is it just a matter of putting /usr/bin/mksh into etc/shells file as per below?
Yes, just so.
Because it is a packaging bug you will have to remember to remove the line if you ever remove the package.
Alternatively, try one of my AUR mksh versions, they are packaged correctly and will manage /etc/shells for you O:)

I will give it a try. Cheers.

Head_on_a_Stick · 2017-11-08 07:45:36

^^ Actually, thinking about this Alpine needs dbus-x11 to work in X:

https://pkgs.alpinelinux.org/packages?n … aintainer=

So maybe Mr. Green doesn't want to mess around with that, which is fair enough.

ohnonot · 2017-11-08 20:57:48

i don't understand why so many people use the word "bashism" as if it was something bad.

some time back i had an epiphany when i realised how much faster dash executes compared to bash, and i started writing scripts for it, instead of bash.
however, i very soon realised that it has limitations and instead of resorting to external utilities & pipes, i can use pure bash to script that.
by now i have a good rule of thumb for how simple a script can be to benefit from dash, and how complex to benefit from bash.

you just use the right tool for the job.

(of course i have not yet compared to ksh and mksh and zsh etc., and i suspect dash might only implement a subset of what POSIX encompasses)

Head_on_a_Stick · 2017-11-08 21:33:59

ohnonot wrote:

why so many people use the word "bashism" as if it was something bad

Bashisms aren't bad per se but sh scripts run quicker (unless the bashisms themselves allow a performance advantage) and are lighter on resources, provided /bin/sh isn't linked to bash (as it is in Arch).

Also, the added features of bash will inevitably introduce extra bugs and vulnerabilities.

ohnonot wrote:

i suspect dash might only implement a subset of what POSIX encompasses)

Dash is described as a "POSIX-compliant shell" so it should have everything defined in the standard.

ratcheer · 2017-11-08 23:34:09

I'm currently reading the mksh web page. It is hilarious (to a tech nerd). E.g., "An inofficial port for OpenBSD is available. Nobody dares commit it though, so it only gets updated on request.", among other snide comments.

Tim

Head_on_a_Stick · 2017-11-09 07:04:06

^ Yes, the MirBSD developer used to be an OpenBSD dev but he had a difference of opinion with Theo de Raadt.

I keep meaning to ask him to update his OpenBSD port 'cos it won't build in my -current system but I haven't plucked up the courage yet

malm · 2017-11-10 22:34:51

@ohnonot: Fair challenge. Please don't take my previous post to mean that I don't like bash. In fact, I do quite like it and have probably written more script in bash than anything else. And I absolutely agree with you, it depends on what you're using if for.

The reasons that my "taste" is leaning towards POSIX shell compliance are slightly older/deeper; and they have nothing to do with speed and security. For the types of scripts I write (glue for other programs), speed generally isn't a priority. If it was, I would probably use C or python. I have little knowledge of shell security, so wouldn't want to comment on that.

So what is it then? It think it comes from having wasted too much time re-writing code and a fear of things breaking. Some of these scars are portability related. And of course, it's not just "shell" but also all the programs called from the shell scripts. Many commands (e.g. ps, grep, sed, find) come with various extensions or implementation specific features. If any of these do not behave as you had hoped, the script often fails in spectactular ways (from experience )

I guess most coders eventually conclude that good code doesn't make assumptions that might not hold true in the future, fails early, is clean/simple, etc, etc; and in the end they look for commonality, standards, specifications and APIs that don't change too much. So whether you are writing html/js/ccs to work on all common browsers, or C89/99/11 to compile on common BSD/Linux platforms (or even Windows/OSX) or anything in-bewteen, the thought of a standard becomes quite appealing. For most Unix shells, the POSIX shell standard is this last common reference point (="highest common denominator").

Now, please don't think that I'm writing all this from the pious position of a good programmer. I make every coding mistake going. And maybe I should re-think. I suppose bash is rather dominant in the Linux world, and maybe bash4 is a good cross-platform standard. Food for thought.

ohnonot · 2017-11-11 09:04:45

^ no problem; i wasn't refering to you personally anyway.
that word is just some sort of fashionable thing to say dismissively in certain communities.
strangely, nobody says "zshisms"...

anyhow, it depends on the job:

Head_on_a_Stick wrote:

sh scripts run quicker (unless the bashisms themselves allow a performance advantage) and are lighter on resources, provided /bin/sh isn't linked to bash (as it is in Arch).

PS:
i read somewhere that bash, if invoked via /bin/sh runs a stripped-down version of itself.

Head_on_a_Stick · 2017-11-11 14:13:36

ohnonot wrote:

i read somewhere that bash, if invoked via /bin/sh runs a stripped-down version of itself.

From bash(1):

If bash is invoked with the name sh, it tries to mimic the startup behavior of historical versions of sh as closely as possible, while conforming to the POSIX standard as well. [...] When invoked as sh, bash enters posix mode after the startup files are read.

Last edited by Head_on_a_Stick (2017-11-11 14:14:30)

Steve · 2017-11-11 14:52:48

i like the fact that mksh/ksh does not have a history ootb, makes the human memory work.

ohnonot · 2017-11-11 16:53:23

Head_on_a_Stick wrote:

ohnonot wrote:
i read somewhere that bash, if invoked via /bin/sh runs a stripped-down version of itself.
From bash(1):
If bash is invoked with the name sh, it tries to mimic the startup behavior of historical versions of sh as closely as possible, while conforming to the POSIX standard as well. [...] When invoked as sh, bash enters posix mode after the startup files are read.

it does not mention making itself lighter/faster.
i might have misread that.

Colonel Panic · 2019-04-09 20:00:44

I recently installed one called fish (short for the friendly interactive shell) in Debian. I'm not acquainted yet with most of its features but I like the different coloured text (it allows for 256 colours) in the prompts.

Here's the wiki for it, and a cheat sheet mentioned on the talk page;

https://en.wikipedia.org/wiki/Friendly_ … tive_shell

https://www.cheatography.com/myounkin/c … ish-shell/

Last edited by Colonel Panic (2019-04-09 20:02:41)

Martin · 2019-04-09 20:47:43

Its own web states "Finally, a command line shell for the 90s" -- sounds 'promising' :-)

The latest release is dated Feb. 19, 2019 so I guess it is only the slogan that is lagging.

/Martin

#21 2017-11-08 07:14:23

Re: What the shell? Bash, KornShell & zsh

#22 2017-11-08 07:18:44

Re: What the shell? Bash, KornShell & zsh

#23 2017-11-08 07:27:52

Re: What the shell? Bash, KornShell & zsh

#24 2017-11-08 07:32:57

Re: What the shell? Bash, KornShell & zsh

#25 2017-11-08 07:34:53

Re: What the shell? Bash, KornShell & zsh

#26 2017-11-08 07:36:39

Re: What the shell? Bash, KornShell & zsh

#27 2017-11-08 07:40:24

Re: What the shell? Bash, KornShell & zsh

#28 2017-11-08 07:44:41

Re: What the shell? Bash, KornShell & zsh

#29 2017-11-08 07:45:36

Re: What the shell? Bash, KornShell & zsh

#30 2017-11-08 20:57:48

Re: What the shell? Bash, KornShell & zsh

#31 2017-11-08 21:33:59

Re: What the shell? Bash, KornShell & zsh

#32 2017-11-08 23:34:09

Re: What the shell? Bash, KornShell & zsh

#33 2017-11-09 07:04:06

Re: What the shell? Bash, KornShell & zsh

#34 2017-11-10 22:34:51

Re: What the shell? Bash, KornShell & zsh

#35 2017-11-11 09:04:45

Re: What the shell? Bash, KornShell & zsh

#36 2017-11-11 14:13:36

Re: What the shell? Bash, KornShell & zsh

#37 2017-11-11 14:52:48

Re: What the shell? Bash, KornShell & zsh

#38 2017-11-11 16:53:23

Re: What the shell? Bash, KornShell & zsh

#39 2019-04-09 20:00:44

Re: What the shell? Bash, KornShell & zsh

#40 2019-04-09 20:47:43

Re: What the shell? Bash, KornShell & zsh

Board footer