Bashism in /etc/rc.d/rc.S

dederon · 06-07-2014, 08:52 AM

as an experiment (and to get rid of bash) i changed /bin/sh to point to /bin/mksh.

the boot process fails at line 109 in /etc/rc.d/rc.S:

eval LUKSARRAY=( $line )

This line, and the following lines

LUKS="${LUKSARRAY[0]}"
DEV="${LUKSARRAY[1]}"
PASS="${LUKSARRAY[2]}"
OPTS="${LUKSARRAY[3]}"

look like bash code to me. Affected is X86_64 current and i686 14.1.

I am not an shell expert, can someone confirm this? Or provide a simple solution? Otherwise I will sot down and write a patch to solve this issue.

heiko

jpollard · 06-07-2014, 09:18 AM

Why would you switch to the korn shell?

If you think that little bashism is bad, just wait... nearly all the startup scripts have bashisms in them.

I could understand switching to something like ash or busybox (useful for very small distributions)... but the korn shell?

GazL · 06-07-2014, 09:21 AM

Yep, unfortunately a number of important Slackware initscripts contain bashisms.

Gilbert did some nice work on POSIX compliant startup-scripts a while back, which you may find useful:
http://www.linuxquestions.org/questi...1/#post5156115

Only problem is that once you start making changes like this you're stepping outside of "Official Slackware" and that may make your system maintenance more difficult when Pat ships a new set of init-scripts.

GazL · 06-07-2014, 09:28 AM

Quote:

Originally Posted by jpollard

Why would you switch to the korn shell?

Maybe he just prefers it, or wants a sh that is more POSIXly correct. Personally, I'd also prefer that /bin/sh didn't point to bash.

dederon · 06-07-2014, 09:42 AM

Quote:

Originally Posted by GazL

Gilbert did some nice work on POSIX compliant startup-scripts a while back, which you may find useful:
http://www.linuxquestions.org/questi...1/#post5156115

i wonder why i missed this topic.

i don't mind using bash for the rc scripts, but if bash is required a "/bin/bash" shebang line should be used instead of "/bin/sh".

Didier Spaier · 06-07-2014, 10:29 AM

Well, I think that Pat just follows the old saying here "if it ain't broke, don't fix it". If he were to rewrite all the init scripts from scratch, maybe he would use another syntax here and there. But there is no need for that as far as I know (please no more flame war about _you_know_what_).

allend · 06-07-2014, 10:50 AM

I giggled when I saw this recently.
From pm-functions (part of pm-utils)

Code:

#!/bin/sh
...
# Simple little logging function.
# We do it this way because 'echo -n' is not posix.
log()
{
	is_set "$LOGGING" || return 0;
	local fmt='%s\n'
	[ "$1" = "-n" ] && { fmt='%s'; shift; }
	printf "$fmt" "$*"
}
...
# always fall back to kernel methods if nothing else was declared

if [ -z "$SUSPEND_MODULE" ]; then
	if grep -q mem /sys/power/state; then
		SUSPEND_MODULE="kernel"
		do_suspend() { echo -n "mem" >/sys/power/state; }
	elif [ -c /dev/pmu ] && pm-pmu --check; then
		SUSPEND_MODULE="kernel"
		do_suspend() { pm-pmu --suspend; }
	elif grep -q standby /sys/power/state; then
		SUSPEND_MODULE="kernel"
		do_suspend() { echo -n "standby" >/sys/power/state; }
	fi
fi

Just an example of POSIX compliance being inconsistently applied in upstream and how POSIX compliance can result in some ugly code constructions.

BTW There are also bashisms in the code, despite the /bin/sh shebang.
Removing bash is a larger task than just looking at the init scripts.

drmozes · 06-07-2014, 11:34 AM

Quote:

Originally Posted by Didier Spaier

Well, I think that Pat just follows the old saying here "if it ain't broken, don't fix it". If he were to rewrite all the init scripts from scratch, maybe he would use another syntax here and there. But there is no need for that as far as I know (please no more flame war about _you_know_what_).

Well, what would the point be? bash is a 'required' package in Slackware, meaning that we know some parts of the OS rely upon it.
You'd remove bash at your peril.

I added bashisms into the initrd 'init' script because it meant I could achieve a string manipulation inside of bash rather than forking to some other utilities. In my opinion since you're using a particular language which is mandated to be present, you should exercise its abilities where possible - particularly if it helps improve efficiency.

If these scripts were intended to be used outside of Slackware then it would make sense to make them as POSIX compliant as possible to maximise their usability. But they aren't.

Didier Spaier · 06-07-2014, 12:09 PM

Quote:

Originally Posted by drmozes

I added bashisms into the initrd 'init' script because it meant I could achieve a string manipulation inside of bash rather than forking to some other utilities.

I guess you mean /etc/rc.d/rc.S in the initrd? I ask because in Slackware initrd as well as in intrd-versatile.img (I just had a look there) /sbin/init links to /bin/busybox.

gnashley · 06-07-2014, 12:14 PM

Any initrd is a special case. In this case, whether you mean the intrd from the installer, or one generated by mkinitrd, bash is not included. rc.S and all other init scripts are not used by the initrd. Any scripts run by the initrd will be busybox/sh compatible -as are doinst.sh scripts.

Didier Spaier · 06-07-2014, 12:39 PM

Quote:

Originally Posted by gnashley

In this case, whether you mean the intrd from the installer, or one generated by mkinitrd, bash is not included.

Bash is included at least in initird-versatile.img for Slackware ARM, I just checked, and it is a standalone executable.

Quote:

rc.S and all other init scripts are not used by the initrd.

/etc/rc.d/rc.S is included and used in Slackware installer's initrd. Of course that's not the same as in the installed Slackware.

Quote:

Any scripts run by the initrd will be busybox/sh compatible -as are doinst.sh scripts.

That's what I thought, but if I understand well what Stuart said that's wrong. I didn't check myself (yet).

drmozes · 06-07-2014, 01:34 PM

Quote:

Originally Posted by Didier Spaier

I guess you mean /etc/rc.d/rc.S in the initrd? I ask because in Slackware initrd as well as in intrd-versatile.img (I just had a look there) /sbin/init links to /bin/busybox.

I was confused where I'd made the change- it was actually mkinitrd. One would have to be careful with the initrd itself since it only has Busybox. The installer uses bash.

jpollard · 06-07-2014, 01:36 PM

About the only place I would expect bashisms to be rare would be those multi-platform packages that are expected on things like AIX and SunOS. Though even there, bash is also frequently installed on the system.

TommyC7 · 06-07-2014, 01:38 PM

Quote:

dederon:
LUKS="${LUKSARRAY[0]}"
DEV="${LUKSARRAY[1]}"
PASS="${LUKSARRAY[2]}"
OPTS="${LUKSARRAY[3]}"

Yes these are bashisms.

First, the LUKSARRAY array is created via:

Code:

cat /etc/crypttab | grep -v "^#" | grep -v "^$" | while read line; do ... ; done

It removes empty lines and any commented lines then reads each line. Each line that is read gets put into an array and each element of the array is then put into it's own variable.

On a secondary note, that could be replaced with:

Code:

egrep -v '(^#|^$)' /etc/crypttab | while read -r line; do ... ; done

Quote:

as an experiment (and to get rid of bash) i changed /bin/sh to point to /bin/mksh.

I don't know too much about mksh specifically, but ksh itself still comes with arrays (some of them are interchangeable with bash-arrays). So even by pointing the symlink to ksh there might be some things that you missed in this little endeavor.

I see a related thread in the "Similar Threads" section and it asks "anyone uses ash as /bin/sh?" which is probably the closest to a POSIX/bourne shell that Slackware has.

There are some things that aren't part of the bourne shell or defined by POSIX in the almquist shell (local for example), but it's pretty close.

GazL · 06-07-2014, 01:57 PM

I actually don't mind bash when it's running in bash mode, and some of the bashisms are actually quite useful. It's when it's trying to take on its POSIX persona when run as 'sh' that you start to hit problems, particularly around shell invocation.

BTW, doesn't debian use 'dash' to provide their /bin/sh?