Randy McMurchy wrote these words on 01/29/06 18:49 CST: > [snip all] Here is an update. Please, if you have a few minutes, check for grammar but really check for technical accuracy. I would appreciate any comments. I feel pretty good about it, and this time I'm finished, but much has been added and/or changed.
(You may see some weird wrapping of long commands, but will be correct in the final. I set my line length at 72 for this email and some commands barely extend past that. Additionally, because this was copied from formatted HTML, you don't see some of the formatting here: quotes, commands bold, etc.) ======================================================================== Automated Building Procedures (sect2 header) There are times when automating the building of a package can come in handy. Everyone has their own reasons for wanting to automate building, and everyone goes about it in their own way. Creating Makefiles, Bash scripts, Perl scripts or simply a list of commands used to cut and paste are just some of the methods you can use to automate building BLFS packages. Detailing how and providing examples of the many ways you can automate the building of packages is beyond the scope of this section. This section will expose you to using file redirection and the yes command to help provide ideas on how to automate your builds. File Redirection to Automate Input (sect3 header) You will find times throughout your BLFS journey when you will come across a package that has a command prompting you for information. This information might be configuration details, a directory path, or a response to a license agreement. This can present a challenge to automate the building of that package. Occasionally, you will be prompted for different information in a series of questions. One method to automate this type of scenario requires putting the desired responses in a file and using redirection so that the program uses the data in the file as the answers to the questions. Building the CUPS package is a good example of how redirecting a file as input to prompts can help you automate the build. If you run the test suite, you are asked to respond to a series of questions regarding the type of test to run and if you have any auxiliary programs the test can use. You can create a file with your responses, one response per line, and use a command similar to the one shown below to automate running the test suite: make check < ../cups-1.1.23-testsuite_parms This effectively makes the test suite use the responses in the file as the input to the questions. Impressive, don't you think? Occasionally you may end up doing a bit of trial and error determining the exact format of your input file for some things, but once figured out and documented you can use this to automate building the package. Using yes to Automate Input (sect3 header) Sometimes you will only need to provide one response, or provide the same response to many prompts. For these instances, the yes command works really well. The yes command can be used to provide a response (the same one) to one or more instances of questions. It can be used to simulate pressing just the Enter key, entering the Y key or entering a string of text. Perhaps the easiest way to show its use is in an example. First, create a short Bash script by entering the following commands: cat > blfsyestest1 << "EOF" #!/bin/bash echo -n -e \\n\\n"Please type something (or nothing) and press Enter ---> " read A_STRING if test "$A_STRING" = ""; then A_STRING="Just the Enter key was pressed" else A_STRING="You entered '$A_STRING'" fi echo -e \\n\\n$A_STRING\\n\\n EOF chmod 755 blfsyestest1 Now run the script by issuing ./blfsyestest1 from the command line. It will wait for a response, which can be anything (or nothing) followed by the Enter key. After entering something, the result will be echoed to the screen. Now use the yes command to automate the entering of a response: yes | ./blfsyestest1 Notice that piping yes by itself to the script results in y being passed to the script. Now try it with a string of text: yes 'This is some text' | ./blfsyestest1 The exact string was used as the response to the script. Finally, try it using an empty (null) string: yes '' | ./blfsyestest1 Notice this results in passing just the press of the Enter key to the script. This is useful for times when the default answer to the prompt is sufficient. This syntax is used in the Net-tools instructions to accept all the defaults to the many prompts during the configuration step. You may now remove the test script, if desired. File Redirection to Automate Output (sect3 header) In order to automate the building of some packages, especially those that require you to read a license agreement one page at a time, requires using a method that avoids having to press a key to display each page. Redirecting the output to a file can be used in these instances to assist with the automation. The previous section on this page touched on creating log files of the build output. The redirection method shown there used the tee command to redirect output to a file while also displaying the output to the screen. Here, the output will only be sent to a file. Again, the easiest way to demonstrate the technique is to show an example. First, issue the command: ls -l /usr/bin | more Of course, you'll be required to view the output one page at a time because the more filter was used. Now try the same command, but this time redirect the output to a file. The special file /dev/null can be used instead of the filename shown, but you will have no logfile to examine: ls -l /usr/bin | more > redirect_test.log 2>&1 Notice that this time the command immediately returned to the shell prompt without having to page through the output. The last example will use the yes command in combination with output redirection to bypass having to page through the output and then providing a y to a prompt. This technique could be used in instances where otherwise you would have to page through the output of a file (such as a license agreement) and then answer the question of do you accept the above?. For this example, another short Bash script is required: cat > blfsyestest2 << "EOF" #!/bin/bash ls -l /usr/bin | more echo -n -e \\n\\n"Did you enjoy reading this? (y,n) " read A_STRING if test "$A_STRING" = "y"; then A_STRING="You entered the 'y' key" else A_STRING="You did NOT enter the 'y' key" fi echo -e \\n\\n$A_STRING\\n\\n EOF chmod 755 blfsyestest2 This script can be used to simulate a program that requires you to read a license agreement, then respond appropriately to accept the agreement before the program will install anything. First, run the script without any automation techniques by issuing ./blfsyestest2. Now issue the following command which uses two automation techniques, making it suitable for use in an automated build script: yes | ./blfsyestest2 > blfsyestest2.log 2>&1 If desired, issue tail blfsyestest2.log to see the end of the paged output, and confirmation that y was passed through to the script. Once satisfied that it works as it should, you may remove the script and log file. Finally, keep in mind that there are many ways to automate and/or script the build commands. There is not a single correct way to do it. Your imagination is the only limit. -- Randy rmlscsi: [GNU ld version 2.15.94.0.2 20041220] [gcc (GCC) 3.4.3] [GNU C Library stable release version 2.3.4] [Linux 2.6.10 i686] 12:13:00 up 127 days, 21:37, 3 users, load average: 1.18, 1.05, 0.65 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
