By my own experience, busybox ash scripts are running without problem in gnu bash but not viceversa. Therfore gnu bash should be considered a super-set in terms of scripting capabilites compared to near complete busybox ash.
Because of this, reverting back the default shell to gnu bash should not create - presumably - no any problem unless very peculiar corner cases are triggered. However, those applications that need gnu bash should call it expressely:
-
scripts: with the proper shebang
#/bin/bashor#/usr/bin/env bash -
executable: forking or childing with
/bin/bash
However, this sane approch fails if the busybox or a package installed in /bin/bash a link to busybox executable. This should be considered a mistake, in any system that can potentially host the gnu bash or it for which with gnu bash was a long-term referencing shell interpreter.
Thus regression is a correctly chosen word in the title of this post, IMHO.
Issues related to qCommand found on 4.5.0.19
Creating an icon for executing a command, it happens that:
-
the command spawn an opening application that stays on the home screen much longer the comand completed when the command complete almost immediately and sucessfully even if
kill -9 $$orkill -9 $PPIDhas been added at the end. Probably is about a timeout in the apps launcher. -
a command icon created by
qCommandcannot be deleted as any other application, Moreover, it is not possible to remove it even if the original script inqCommandis deleted but this makes sense because I may want remove the command without removing the icon, and viceversa.
I hope this helps, R-
UPDATE
I add the suggestion to restore the /bin/bash symlink to the original bash shell in my quick start guide in hints and tips section. 