coreutils instructions

Bruce Dubbs bruce.dubbs at
Mon Mar 23 15:52:53 PDT 2009

Agathoklis D. Hatzimanikas wrote:
> On Mon, Mar 23, at 07:12 Dan Nicholson wrote:
>> On Fri, Mar 20, 2009 at 4:44 PM, Bruce Dubbs <bruce.dubbs at> wrote:
>> If you were looking at a system (not just a computer system) and you
>> found that one part took twice the resources and twice as long to
>> start up as another part offering similar functionality, why would you
>> dismiss it?
> In a perfect world? You have to adopt the best technology.
> But in the case of Linux, Bash is the single most sacred piece of code.
> Objectively, Dash is more suitable for login and system scripts than Bash,
> because is faster,

Yes, but is it significant

  more stable

this is an unsupported assertion

  and offers portability

portability to what?

  and compliance with
> POSIX specifications, which is very important in a project like ours.

Dash is arguably less in compliance than bash as it does not support the LINENO 
variable specified in the PSOIX standard.

The advantages of dash/ash are that they are smaller and faster.  The real 
question is whether the speed differences and size are significant for an LFS 

The drawback to dash/ash is that they offer fewer features.  It's a trade off.

>> Maybe the original part offers better features than the
>> replacement, but that doesn't mean the other facts can be ignored.
> And in the case of interactivity, Zsh offers an unquestionable superior
> technology than any other existing shell.

Perhaps.  I really haven't looked at zsh much.

> But again, if the purpose of Bash is to write scripts for administrative
> tasks, in my opinion and if a script is going to be more that few lines of
> code, is much better to write it in one of the popular and portable scripting
> languages, like Python and Ruby (even Perl!), rather than to rely on Bash
> extensions.

That's an option.  You can even use php for scripts.  It's really a nice language.

Perl is difficult because it has so many side effects and lends itself to 
writing code that is difficult to understand if you are not a Perl expert.

Python has the drawback that it is dependent on blank space.  It's not something 
that I like.  YMMV.

> As a side note, and speaking for the future of shell.
> In my opinion, (the) shell nowadays has reached its limits and honestly
> its not that appealing to the young generation (I don't know for you but
> for me the latter is really crucial).
> This mostly happens, because a young kid which invests some of his valuable
> time (just to be a little productive with the shell), needs to learn a
> series of commands, with its own syntax and idiosyncrasy (sometimes really
> complex), and then to chain them via pipes (for more complex tasks).
> Most of the times this is ugly, fragile and sometimes the result is
> unexpected, though through experience this way can be truly efficient (I 
> am not denying it).
> Count on this that most kids are familiar with languages with excellent
> syntax (like Python) or beautiful syntax (like Ruby's).
> For what? Just to work in a resource hog, ugly and plain slow bloating
> environment like Bash.

The real power of bash is at the command line, not as a scripting language. 
Personally, I think anything over about 200 lines should not be done in any 
shell variant.

Perhaps I should look at ksh...

> And try to compare with a shell concept, where everything (directories
> and files) are plain objects and you just send messages (applying
> methods) to those objects.
> What we take is consistent syntax (no matter the kind of operations you
> apply), and a powerful language in our disposal with almost no limitation.
> E.g., (an example from a Ruby based experimental shell concept named Rush)
> dir = home['somedir/']
> dir['*.txt'].each {|f| f.destroy}

In bash: rm -f $HOME/somdir/*.txt

You really think Ruby is easier?

> However if this is not going to happen, which is quite possible, I would
> prefer to use #!/bin/bash rather than #!/bin/sh in our scripts.
> Keep /bin/sh for only POSIX compliant scripts.

That's a reasonable position.

> Oh well, almost all. I'd rather get rid of Bash.

One other comment.  For a commercial distro, the vast majority of users will 
never look at a script let alone write them.  This is completely different from 
the typical LFS user that, as a minimum, creates scripts in Chapter 7.  I would 
bet a reasonable amount that 99% of users customize at least the .bash_profile 
and .bashrc scripts.  As one who writes scripts, my preference is power over speed.

I have one bash script that I run fairly often from the command line that builds 
an application I'm developing (about 150K SLOC C++).  It's 17 lines long, but 
three lines are blank.  Also, all my build scripts are bash.  They generally run 
about 40-60 lines, but almost half of the lines are blank or comments.

Actually this whole discussion is about what interpreter should be used for the 
boot sequence.  Does a 10-20% decrease in boot time justify the time spent to 
make the scripts compatible with an interpreter that we don't even install in 
LFS?  Since my workstation has an uptime of 34 days and my servers an uptime of 
117, 1217, and 19 days respectively, I say no.  My distro, my rules.  :)

   -- Bruce

More information about the lfs-dev mailing list