LinuxQuestions.org - Bashism in /etc/rc.d/rc.S

Page 1 of 4

Show 50 post(s) from this thread on one page

- Slackware (https://www.linuxquestions.org/questions/slackware-14/)

- - Bashism in /etc/rc.d/rc.S (https://www.linuxquestions.org/questions/slackware-14/bashism-in-etc-rc-d-rc-s-4175507325/)

dederon

06-07-2014 08:52 AM

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

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 (Post 5184060)

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 (Post 5184063)

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 (Post 5184091)

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 (Post 5184116)

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 (Post 5184131)

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 (Post 5184129)

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?

All times are GMT -5. The time now is 02:58 PM.

Page 1 of 4

Last »

Show 50 post(s) from this thread on one page