Scripts refuse to run with "bash", only use "ash"

Installing and Using OpenWrt
1

I am trying to run a bash script. Have installed bash via "opkg install bash". Can see bash and use it from command line:

bash --version
GNU bash, version 5.2.32(1)-release (x86_64-openwrt-linux-gnu)
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

While testing a script that was failing, I noticed the script interpreter wants to use "ash", even when the she-bang says to use "bash". I tested this with "echo $SHELL":

Script body:

root@OpenWrt:/caboy# cat test.sh 
#!/bin/bash

echo "shell: $SHELL"

Running script:

root@OpenWrt:/caboy# ./test.sh 
shell: /bin/ash

Even when I explicitly type "bash test.sh", the behavior is the same.

Anyone know what could be causing this? Did I do something dumb?

I have this version of OpenWRT: OpenWrt 24.10.2

2 
SHELL=/bin/false ./tess.sh
3

echo $SHELL ?

4

This does change the $SHELL var value, but does not actually change the interpreter being used. The script still runs with "ash".

To replicate:

My script has this:

#!/bin/bash

# ... (truncated)

units=("B" "KiB" "MiB" "GiB" "TiB")

Which gives an error when run:

./foo.sh: line 8: syntax error near unexpected token `('
./foo.sh: line 8: `    units=("B" "KiB" "MiB" "GiB" "TiB")'

From the bash command line, I can copy & paste that same line and it runs fine:

root@OpenWrt:/caboy# units=("B" "KiB" "MiB" "GiB" "TiB")
root@OpenWrt:/caboy# echo $units
B
5

Just wondering if your script has Windows-style line endings (CRLF)? Cuz if it does then the kernel is trying to execute /bin/bash\r which fails causing a fallback to the system's default shell ash..

6

Not reproducible, e.g.:

#!/bin/bash

units=("B" "KiB" "MiB" "GiB" "TiB")
cnt=1
for u in "${units[@]}"; do
  echo "$cnt $u"
  ((cnt++))
done

Output:

~# ./test.sh 
1 B
2 KiB
3 MiB
4 GiB
5 TiB

Probably you've borked your script with (invisible) special characters that are not supported by Linux.

7

Everything you are trying is from an ASH shell.
The stripped down OpenWrt ash does not read the shebang, it does not need to 99.99% of the time. It never has, this is not something new and it is not a bug.

You can:

  • Run, one way or another, bash to start a bash shell, then run your bash script.
  • Make bash the default shell (editing /etc/passwd), but this is somewhat risky as one day you might sysupgrade and keep config only to find bash is not installed leaving you bricked.

Now your example:
When you open a terminal session, it is an ash terminal session (unless you changed the default in /etc/passwd).

If you just pipe the required command into bash, you have to escape the double quotes so ASH knows what you mean:

root@meshnode-8ecb:/tmp# echo "units=(\"B\" \"KiB\" \"MiB\" \"GiB\" \"TiB\")" | bash; echo "$units"

root@meshnode-8ecb:/tmp#

But we got a blank line!
This is because the bash shell we just invoked took its variables with it when it terminated.

So get bash to do the echo, but now we also need to escape the dollar sign in $units:

root@meshnode-8ecb:/tmp# echo "units=(\"B\" \"KiB\" \"MiB\" \"GiB\" \"TiB\"); echo \"\$units\"" | bash
B
root@meshnode-8ecb:/tmp#

Job done.

If your requirement is just a few bash commands, this is the best way to do it.

If it is running some bash scripts manually, then start bash from ash and run them, exiting back to ash afterwards.

If you are running lots of bash scripts automatically for your particular use case, maybe carefully consider changing the default.

1 Like
8

Nope, see my example above ...

9

OOOH! I stand corrected!
This has not always been the case. Admittedly I have not needed to use bash on OpenWrt much since ~2018 and back then....
I just searched the wiki, and here it is:

Shebang Operator in OpenWrt

Another outdated wiki page.

My example of piping commands to bash still stands however.

EDIT: I updated the wiki.

3 Likes
10

If you want to convert bytes to human-readable units (as your code seems to suggest), we have this implemented as a function in adblock-lean, and it doesn't require bash:

You can re-use the code almost as is, provided that your work has a license compatible with GPLv2.

1 Like
11

Winner winner, chicken dinner. This is the answer. Borked characters goofing the script. Details on that further down.

It turns out my test was bad too. The env var $SHELL is not helpful in this case.

I did another test updating my script to search "ps -ef" for its own PID '$$'. The process table shows "bash" is running the script.

Script contents:

root@OpenWrt:/caboy# cat test.sh 
#!/bin/bash

echo "shell: $SHELL"

ps -ef | grep $$

Script output:

root@OpenWrt:/caboy# ./test.sh 
shell: /bin/ash
root      5114  4997  0 22:58 pts/1    00:00:00 /bin/bash ./test.sh

Details on borked chars:
The borked characters were not "\n\b" (newline, line-break). I actually don't know what it was, but I do know what I did to fix. I deleted all leading whitespace on each line (formatting whitespace), then put the whitespace back in manually.

Which explains why something like this would fail in the script, but work fine when copy pasted into the command line:

    units=("B" "KiB" "MiB" "GiB" "TiB")

I don't know what those borked whitespace characters were. The code was written on a different system, then emailed to myself, and copy pasted into a terminal. Lots of places things could have gone wrong.

Thanks all for chiming in.

4 Likes
12

I don't want to be pedantic, but I don't think your conclusion could be found in the wiki, it just stated a '#!/bin/bash' she-bang wouldn't work, without telling why. I think it just stood there because by default no bash is available.
AFAIK the she-bang is not read by ash. Ash just (after forking) hands the file(path) over to the loader in libc (exec..()) which does the actual work.

13

No, please do be, it helps to get down to the to the possibilities.
I did not come to my conclusion just by reading the outdated wiki page, but by previous experience way back with LEDE (17x) and OpenWrt 18x on a particular backporting project that used a lot of bash scripts.
My conclusion was reinforced by the wiki page when I read it the other day.

With your pedantic hat on, do you have any suggestions for the wiki page? It is still very much an old document needing a rewrite in my opinion.

14

Well, the answer on the question if bash can be installed is a bit conservative. Although it won't hurt to use flash memory sparingly, many routers nowadays can install bash (or vim) on internal flash without problems. Yet the answer on the question should not be something like 'sure, go ahead!', as there are still enough routers where that's not true.
Further the line

changed your default shell to #!/bin/bash

is wrong. It should be /bin/bash here.

And last, I wonder if the section you changed shouldn't be expanded with the comment that nowadays you should consider using ucode for OpenWrt scripts. On the other hand, as far as I could find ucode is not documented in the wiki yet.

15

Now you've done it, mentioned the Top Secret "uc#e" project. Run and hide! No-one is supposed to know anything about it... :dash:

Seriously though, ucode is of little use when considering the huge volume of (b)ash scripts and scripting examples out there.
Maybe one day someone will write a useful wiki guide.... I wouldn't be holding my breath if I was waiting though...

The whole document should be re-written in my opinion. Any volunteers?

16

Beyond flash usage (and upgrade safety), there is another issue making this not advisable. bash (still) is rather slow to start, while you won't notice this on x86 worth using, it is very noticable on weak CPUs (mips and friends). Until ~15 years ago, I was still using a SUN SPARCstation 20 with a TI SuperSPARC SM50 CPU (50 MHz, sun4m, 196 MB RAM, cg6 graphics) - using bash as interactive/ login shell caused very noticable delays on getty, ssh, etc. Changing the default user shell to busybox-ash brought a massive resposiveness improvement, while having more comfort features than the (equally fast) dash.

Modern ARMv8 routers probably won't feel the pain for interactive use anymore, but non-interactive use would still noticably suffer from bash as /bin/sh.

1 Like
17

Happy memories :grin: