Randy McMurchy wrote:
> ========================================================================
>
> 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
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
I still don't like this. It's not slang, but it doesn't add anything.
> 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"
blfs-yes-test1
> #!/bin/bash
>
> echo -n -e \\n\\n"Please type something (or nothing) and press Enter ---> "
I think the string makes more sense as:
'\n\nPlease 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
blfs-yes-test1 (readability)
>
> Now run the script by issuing ./blfsyestest1 from the command line. It
./blfs-yes-test1
> 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
./blfs-yes-test1
>
> 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
./blfs-yes-test1
>
> The exact string was used as the response to the script. Finally, try it
> using an empty (null) string:
>
> yes '' | ./blfsyestest1
./blfs-yes-test1
>
> 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.
Start para here
> 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"
blfs-yes-test2
> #!/bin/bash
>
> ls -l /usr/bin | more
>
> echo -n -e \\n\\n"Did you enjoy reading this? (y,n) "
'\n\nDid 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
blfs-yes-test2
>
> 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.
./blfs-yes-test2
>
> 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
blfs-yes-test2 blfs-yes-test2.log
>
> If desired, issue tail blfsyestest2.log to see the end of the paged
blfs-yes-test2.log
> 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.
-- Bruce
--
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
