Is anyone else installing LFS with shell scripts

As I have been following the instructions for LFS I begun to realize that I could save a lot of retyping by running the commands from scripts. I have got to the point where I expect to install most of the installation from just four or five scripts.

I am seeing some problems and worries. If one installation doesn't go, the script may just go to the next installation. Still, if you have ever had to do a long installation over again, the utility of scripts looms enormously.

Has anyone else applied any scripts in their installations? Basically all you do is type the commands into a text file and 'chmod a+x /TheTextFile' and then type the name of the text file as if it were a command. But all the resources of the shell are available and there is some programmability possible in even the simple bash shell scripts.

I'd try Automated Linux From Scratch, but there does not appear to be a 4.1 profile yet. Any experience here with that?

I'm not trying to be rude... however I thought that the biggest difference between LFS and something like Gentoo was the lack of automation? I thought the reason for LFS was for people who WANTED to compile everything by hand and piece together a linux system bin by bin.

again, I am not trying to be rude and I'm sorry if my reply seems a little harsh... just putting in my $0.02

i don't know much about LFS, but i would say that i's a clever idea , after all i'ts still doing the work of building a system from basically scratch, it's just cutting down on the boring parts and allowing it to be more fun

I agree that the spirit of LFS is to cobble everything together by hand. But the way that you are instructed to assemble LFS really suggest scripts. In fact the scripts I use are just typed directly from the commands given using the vi editor. It really seems so obvious that I imagine the author hoped the reader might catch on. That really is a lot of typing to do to compile all that. Especially if you have to do it over somewhere.

The book is meant more as an educational tool than just a c'n'p fest/exercise in mass scriptage.

Always best to do your first build by hand, then script it all you want afterwards.

I must admit though to primarily using scripts for automating tests of the build method for the pure lfs stuff
( http://www.linuxfromscratch.org/~ryan/scripts/plfs )

If you check those out you may see just how much you have to cater for in your scripts... most of the time it is less effort doing it by hand than maintaining scripts :-)

I looked at your scripts and they are nothing like what I am applying. I can't even tell how they work. The scripts I use are just the commnds copy and pasted from the book. I think going through every step by hand every time is of limited educational use unless you are just learning to use the keyboard with touch typing. Every Linux user should know how to apply scripts since scripts are such an important part of Linux functionality. Scripts really are very, very simple tools. Even a script per section would be a big improvement for many of the more complicated sections.

If you want a scripted install, theres ALFS.

Timothy Bauscher also has a neat little package to generate scripts from the books XML, this is probably what you are looking for...

http://linuxfromscratch.org/~timothy...md-1.0.tar.bz2

Save yourself some typoes^H^H^Hing :-)

Yeah, I agree, my scripts are horribly convoluted :-)
Comes from needing to handle many and varied different versions of packages (hence seds instead of patches) and multiple architectures.
(they're more a test framework than buildscripts)

I'm working on a script right now with what I HOPE to be fairly simple maintenance.

To address the point before, yes, LFS is meant to teach you something the first time you do it. Maybe even the second. But what happens when you have three machines to install it on? How frustrating is it to mis-type a configure/make command only to find out much later in the process that something, somewhere earlier got screwed up, and start the process again.

As for ALFS, I don't know about you folks, but the way it's set up doesn't scream user-friendly. Well, let me re-phrase that, the documentation provided did not give me a sense of "full understanding" in using the tool. All I felt comfortable with was marking EVERYTHING as a compile. If there was an error, well, mark EVERYTHING again. Ultimately, the ALFS approach would be the most robust, but until I feel comfortable with using it, I'll keep working on my scripts.

I believe I'm 90% done with a script to handle the static installation portion of the book. Ideally, the goal would be to automate static compile and shared compile in one script. I'm not sure how feasible that is considering the user must change to root to execute chroot in-between the static and shared stages. I for one, would be timid about giving my script root access. Not to mention someone else running a script they didn't author themselves.

I can post it when I clean it up a little more if anyone is interested. Like I said, the idea is to try and make it fairly easily maintained. I do that by breaking each package compile into basically five commands: pre, cfg, make, install, and post. In theory, each of those five contain a single command (if any at all), but the pre and post commands will typically take the form of "<command> && <command> && ...". Using a few greps, you could see what the commands for any one package are and compare them to the book. If a package changes, it should be reasonably simple to run sed on the script to update that package's commands.

And the script does have error-checking. I am being fairly religious about that. Almost every command verifies good exit status. If a command fails, the script displays the message, and exits with the same failure value. I also intend to add a command-line argument to start the script at a given package; to pick up where you left off in case of an error.

I can post it when I clean it up a little more if anyone is interested.

Sounds great, I would be interested. I'll try and do the same. I guess this would be the difference between LFS and some other "distro". People are apt to be making all kinds of scripts. This is a good thing. Linux users and computer users in general should be more fluent in writing scripts. In Linux especially, it is just too easy.

Hmmm... I can't seem to post it...

LQ says the post is too long... <sigh> Oh well, I guess I could email it, but it's not quite ready yet. I was mainly going to post it for comments on improvement. c'est la vie...

Get yourself a site over at Tripod, that's who hosts my site in my signature. The banner has a link to get set up and I think they allow downloads from a site. Check that first, I guess.

It's up...

My temp Tripod site

and follow the LFS script link on the left. You'll need to right-click, "save as", and remove the ".html" extension it wants to put by default.

If you just follow the link, it'll post it, but it's be badly mis-formed. I just didn't see a way to create a link to directly download a file, but that might be due to a complete lack of knowledge when it comes to HTML.

Anyway, let me know if you think it has promise, is the most horrid thing you've ever seen, or you'e happy with it just the way it is...

I got it! And my first impression is that it is good. Mine is much, much simpler and follows the book more closely, but has no way of bailing out if something doesn't go in right and you can see by my posts that this does happen.

What really mystifies me about your script is the vast amount of text processing that must have gone on. This was a recurring challenge for me in making even my simple script. For example, you have a list of packages. How do you get that into text into the script without typing it out? There must be a way right? There is, but figuring that out was an obstacle for me. I suspect there are many other such tricks. I used vi and cat, but I am sure there are other tools. Did you employ similar tricks in creating your script? How much was actually typed in by hand?

Have you seen Ryan's script below? What do you make of it? I'm not even sure what it is for.

Ryan ... ?

Hehehe, that script has grown since December last year, it was the testing basis of Pure LFS (Currently CVS lfs).

Builds everything against a new glibc to avoid glibc migration issues (see the pure-lfs hint ) and produces a bucketload of log output for checking against.

Probably best to read the hint
http://hints.linuxfromscratch.org/hints/pure_lfs.txt

May make the scripts make a little more sense :-)

Scripts should generally work for many different versions of packages, but YMMV with gcc-3.3 at the moment...
Still more work to do...

The script evolved as I started to type it up. At first, I planned to just copy-and-paste the commands from the book into a script. When I realized I couldn't do that and just run it (I was getting some kind of error), I decided to change it up a bit. Long story short, I looked at other scripts in general, picked up enough information to search through bash's man page, and drew on my knowledge of C to make it as modular as possible.

So, the short-short answer to your question is: I copy-and-pasted the commands from the book. It's an initial investment in time to do that, but will require little maintenance over time. Each new release of the book won't be a complete rewrite; Only a handful of packages (on average) should change. So going through the book and realizing which packages have changed and updating the relevant section of the script should be relatively painless.

I do have greater aspirations than copy-and-paste glory though. Downloading the book in XML format would make it feasible to extract the commands. Essentially that's what nALFS is doing. I wouldn't plan to go that far though. I'm thinking you would rip out the compilation commands in the XML (using greps and cuts), compare them against what the script uses (more greps), and finally, update the script if necessary (sed). And presto! it should work. The reliability of these modifications depends on the reliability of the grep commands properly locating commands to rip out. That's why the names of the variables at the top of the script are so uniform: to help with grep'ing against the script's contents since all the important stuff is assigned to those variables.