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 <[email protected]> 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
system.
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
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
