Obnoxious postings from Google Groups

GangGreene GangGreene at example.com
Wed Nov 7 01:16:48 CET 2012

On Tue, 06 Nov 2012 23:14:40 +0000, Steven D'Aprano wrote:

> On Tue, 06 Nov 2012 11:51:03 -0500, GangGreene wrote:
>> I have just finished a 251 line bash shell script that builds my linux
>> distro from scratch.
> "From scratch"? So if you run it on bare metal with no OS, it works?

It has a host system for build/bootstraping. Then it goes onto an USB 
drive, both as the OS and installation packages (with package manager) 
capable of install on a system without an OS.  Hard drive needed ;)

> But seriously -- bash is a mature, powerful shell. It works well for
> what it does. It has been designed to make it easy[1] to automate system
> admin tasks. It would be astonishing if an experienced, competent bash
> programmer couldn't write an installation tool in bash. By comparison,
> few general purpose programming languages (with the obvious exception of
> perl) are designed for system administration as their primary purpose.
> But... how robust is your script? How many bugs does it contain? Chances
> are you will only use it a handful of times, on the same system. That's
> not a lot of testing to be sure that it is free of bugs, and robust
> against unexpected input.

I have used it for several years and others have used it to build their 
own systems.  I have used it on 586 to the latest multi core systems.

> Hell, even widely used and distributed install scripts written by
> companies with the resources of Ubuntu and Red Hat have a distressing
> tendency to break. Or worse, to behave in unexpected ways.

I am not Redhat or Ubuntu (commercial distros stink) ;)

> Unless you are some sort of bash-scripting über-geek superhero with
> powers beyond those of mortal men, chances are that your script is much
> more buggy and fragile than you imagine. How well does it recover from
> errors? 

It stops on all critical build errors and skips the package on minimal 
errors, giving me a list of skipped packages and status on them at the 
end of the build sequence (so I can fix my errors).  It will also 
download the source package if it is not present in the build directory.  
If I incur any breakage/error ( it can happen a lot ) it stops and 
notifies me.  I then fix the package build script and lather/rinse/repeat 
until I get the package build correct.  It logs all the information into 
build/testing/file listing/dependency requirements into log files.  Then 
the package goes off to a repository holding all the other packages.  The 
directory layout is like this:

   +--section - programming/X window etc
         +----package - python gcc coreutils and contains the
                        build script ( bash script ) and source package.

The build system ( bash scripts ) recurses this directory structure build 
the packages and placing them into

     +-----base - base system packages kernel coreutils etc
     +-----extra - programming packages, xorg etc here

The package manager (written in C) then looks to the repository to 
install/update from the repository.

> Does it leave you with a broken system, half installed?

No. It builds all of the packages and then creates binary/devel packages 
to be installed a new system.  The finished packages go into a repository.
If I update a package only that package is built and placed into the 
repository so all machine can be updated by my package manager.  And yes 
the build script automatically takes care of all build dependencies as 
well as installed binary dependencies for the host installs. It will even 
build itself.

>How easily can you maintain it after three months? Will it work in the
> presence of filenames with newlines in them?

I have maintained it for 8 years, and it can and does handle file names 
with spaces, any valid *nix file name character can be used.

> [1] For some definition of "easy". In my opinion, control structures
> like "for" and "if" in bash are hard to use, hard to read, easy to get
> wrong, give cryptic error messages when you do get them wrong, and are
> ugly. Tests are obfuscated, and as always, the fact that everything is
> text in bash means it is way harder than it needs to be to use rich,
> modern data structures.

Only from a certain points of view.  I use many for loops and no if 
statements.  There is a good alternate for if, easily understandable if 
you know C and boolean logic.  My background is in C and Delphi/Pascal 
and I didn't have problems with bash scripting.  I want to have a go at 

Arch linux "pacman package management/build/delevopment system" is very 
similar to mine.  If you wish to take a look at it.  It is also mostly 
bash scripts with some C and python2/3 to boot.

More information about the Python-list mailing list