[Dev] Setting dash as default shell (or getting rid of bash)
c.haitzler at samsung.com
Fri Sep 27 02:41:53 GMT 2013
On 09/26/2013 10:45 PM, De Marchi, Lucas wrote:
>> -----Original Message-----
>> From: dev-bounces at lists.tizen.org [mailto:dev-bounces at lists.tizen.org] On
>> Behalf Of Aleksander Zdyb
>> Sent: Thursday, September 26, 2013 9:40 AM
>> To: dev at lists.tizen.org
>> Subject: [Dev] Setting dash as default shell (or getting rid of bash)
>> Hello everyone.
>> In order to prepare a minimal distribution of TIZEN 3.0, I'm considering
>> replacing bash as a default shell (/bin/sh) with dash.
>> The goal is to reduce size of image and (possibly) boost performance.
>> My goal is not to kick bash out of TIZEN, but to provide it only as an
>> optional component. It will still be available for installation, if there
>> are any scripts needing it or if user console is to be provided.
>> I've managed to build such an image, where /bin/sh points to dash and it's
>> bootable and functional. However it was impossible to get rid of bash
>> entirely. It's because of some (mostly artificial) dependencies on
>> There are three groups of dependencies on bash:
>> 1. Real dependencies -- scripts relaying on bash functionalities and/or
>> syntax (bashisms ), 2. Artificial dependencies -- scripts declared as
>> bash, but not really using any of its benefits, 3. Spec scripts -- there
>> are many commands using syntactic sugar of bash.
>> It's hard to identify instances of first two groups. Most packets don't
>> mark their dependency on bash in spec files. In some cases, the dependency
>> is automatically revealed by rpm during build. This is however very
>> unreliable and requires building the packages. Moreover it's nearly
>> impossible to track changes in hidden (i.e. automatically
>> found) dependencies.
>> The 3rd group can be eliminated gradually or, if there is a way to
>> preserve bash as default shell in building environment, leaving it as it
>> Now, I would like to ask everyone to:
>> 1. eliminate unnecessary usage of bash in additional scripts provided as
>> source/patches to packages in the future, 2. add Requires/BuildRequires in
>> spec files in case, the package needs bash, instead of relaying on
>> automatic dependency detection, 3. not using bashisms in spec files
>> , 4. share thoughts and ideas on this topic.
> Before going through any of these changes, there are answered questions. How much
> are we saving? Taking a look on my 64bits machine it's 100k vs 720k. Then there
> are packages that still need bash and won't work with dash simply because there
> are useful features in bash. And this may be coming from upstream packages.
> Then in the end you will need both in your system and you save nothing.
> IMO it would make sense only if we depend on a shell during boot, but we don't, or
> at least shouldn't.
>> I will be eliminating dependencies on bash in packages, I encounter while
>> working on the minimal image, I'm preparing.
>> Please share your thoughts and ideas on this topic.
> Sorry, but I'm skeptical about it. Please provide numbers before doing
> changes like this.
i'm kind of skeptical just that we don't use busybox if efficiency is
the goal.. as its yet another level of compactness down from dash. :) i
also think that there may be 2 scenarios. 1 is a build system install or
for developers where y\ou want a full set of complete working tools
(bash, full gnu grep, find, awk, gawk etc.) vs a much leaner runtime
setup where on boot we are not even running any significant scripts thus
busybox is just fine... :) (and if that runtime system becomes a dev
system by installing full versions of these tools, the symlinks are
> Lucas De Marchi
> Dev mailing list
> Dev at lists.tizen.org
The above message is intended solely for the named addressee and may
contain trade secret, industrial technology or privileged and
confidential information otherwise protected under applicable law
including the Unfair Competition Prevention and Trade Secret Protection
Act. Any unauthorized dissemination, distribution, copying or use of the
information contained in this communication is strictly prohibited. If
you have received this communication in error, please notify the sender
by email and delete this communication immediately.
More information about the Dev