Re: Hopefully Someone Will Check and Comment on My Logic [OT Maybe?]
On 03/12/2011 08:00 PM, Neal Murphy wrote:
snipping
OR use:
[ -e file_1 ] [ ! -e file_2 ] {
commands;
}
# equivalent: test -e $file_1 test ! -e file_2 {
OR even use:
[ -e file_1 -a ! -e file_2 ] {
commands;
}
# equivalent: test -e file_1 -a ! -e file_2 {
snipping
Thanks for the insight, Neal. I'm starting to play with the script. In
the above examples are you suggesting that I enclose the names of the
files in quotes? I can't find this syntax in my references. If you are
suggesting it, is it so that no expansion takes place?
Nothing else on your script pokes me in the eye with a sharp stick.
Good.
Thanks again,
Dan
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: Hopefully Someone Will Check and Comment on My Logic [OT Maybe?]
On 03/13/2011 01:06 PM, Dan McGhee wrote:
On 03/12/2011 08:00 PM, Neal Murphy wrote:
snipping
OR use:
[ -e file_1 ] [ ! -e file_2 ] {
commands;
}
# equivalent: test -e $file_1 test ! -e file_2 {
OR even use:
[ -e file_1 -a ! -e file_2 ] {
commands;
}
# equivalent: test -e file_1 -a ! -e file_2 {
snipping
Thanks for the insight, Neal. I'm starting to play with the script. In
the above examples are you suggesting that I enclose the names of the
files in quotes? I can't find this syntax in my references. If you are
suggesting it, is it so that no expansion takes place?
I just found in the fine print of an example. ABS Guide uses it to allow
for spaces.
Nothing else on your script pokes me in the eye with a sharp stick.
Good.
Thanks again.
Dan
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: Hopefully Someone Will Check and Comment on My Logic [OT Maybe?]
On Sat, 12 Mar 2011 19:11:37 -0600
Dan McGhee beesnee...@att.net wrote:
This is what I was hoping to hear--that the logic is sound,but that
there might be a problem in the construct. I've shied away from ( )
and {} in $ xxx statements because I'm really shaky on what they
mean. I've also never seen the ' ' [ ] ' ' construct. I use the
Advanced Bash Scripting Guide as my reference. Thank you for your
feedback. I'll play with this.
Those (the '' thing) were quotes I used for inclusion in text.
Instead of writing
[ blah ]
I just wrote ''[ blah ]'' inline. Remove the quotes (luckily
they enclose empty strings so even if you don't remove them, they
should not change the meaning of the expression).
--
-Aleksandar Kuktin
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: Hopefully Someone Will Check and Comment on My Logic [OT Maybe?]
On Sunday 13 March 2011 14:12:20 Dan McGhee wrote:
On 03/13/2011 01:06 PM, Dan McGhee wrote:
On 03/12/2011 08:00 PM, Neal Murphy wrote:
snipping
OR use:
[ -e file_1 ] [ ! -e file_2 ] {
commands;
}
# equivalent: test -e $file_1 test ! -e file_2 {
OR even use:
[ -e file_1 -a ! -e file_2 ] {
commands;
}
# equivalent: test -e file_1 -a ! -e file_2 {
snipping
Thanks for the insight, Neal. I'm starting to play with the script. In
the above examples are you suggesting that I enclose the names of the
files in quotes? I can't find this syntax in my references. If you are
suggesting it, is it so that no expansion takes place?
I just found in the fine print of an example. ABS Guide uses it to allow
for spaces.
Generally, single- and double-quotes allow for spaces in strings and for null
(or empty) strings. Double-quotes allow $xxx shell variables to be expanded;
single-quotes prevent expansion. Learning to automatically quote strings leads
to long-term hair retention. I usually use quotes because they result in
clearer syntax than one gets when using \ escaping.
var=two words
if [ $var == two words ]; then ... fi
and
var=two\ words
if [ $var == two\ words ]; then ... fi
are equivalent; the quoted form is clearer and is often the only way to make
it work.
Also, I must amend my msg re: the explicit semi-colon I included following the
last command when using the ' { commands; } syntax. I was mistaken. They
aren't necessary when the commands are on separate lines, as in:
... {
command 1
command 2
}
but it won't hurt to have them there. Semi-colons are only needed to terminate
commands when they are on one line, as in:
... { command 2; command 2; }
It is standard, consistent shell syntax.
I thought I tested it both ways before clicking send; clearly I didn't.
N
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: Hopefully Someone Will Check and Comment on My Logic [OT Maybe?]
On 03/12/2011 06:00 PM, Dan McGhee wrote: One thing I want it to do is recover from a failed 'make' or 'install' without have to run the whole script again. This feature *used to* work. It now doesn't. If everything is OK, the script runs from the beginning to the successful end of a build. But if there is a glitch, the recovery doesn't happen. I'm replying to my own original post. Needed to have some stuff that the others snipped to show the error of my ways. The script was doing exactly what I told it to do. There were no problems with variables, syntax or exit status. What I didn't put in my original post, and this is my personal logic error, is that when I exited the script after make, simulating a failed install, it started at make again and not install. Please look at the following sequence. # This one recovers from failed make. if [ -e $logdir/make-`echo $package`.err ] \ [ ! -e $logdir/install-`echo $package`.err ]; then # This one recovers from a failed install if [ -e $logdir/make-`echo $package`.log ] \ [ ! -e $HOME/$package-files.list ]; then # This one does everything through configure, make, make install if [ ! -e $logdir ]; then The order is failed make, failed install and fresh build. If the install fails after make, the conditions exist to make,and the script will start there. So the order of the first two tests needed to be reversed. I did that and everything works the way I want it to. Thanks, Aleksandar and Neal, for your inputs. My syntax is now more elegant in addition to working. I learned a trick from the Advanced Bash Scripting Guide that proved to me that everything was as it should be except what I wanted the script to do. I had inspected and made sure that all the files and directories existed and had the right names. They did. But that didn't mean that the tests were parsing everything correctly, so I wanted to do something to test the test. I stumbled on this which is exactly what I needed: if [ -e $file ]; then echo $file exists else echo $file does not exist fi Inserting two loops like this to check my tests is what lead me to realize that the test order was not correct. Once again, thanks for the responses. I learned quite a bit. Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Hopefully Someone Will Check and Comment on My Logic [OT Maybe?]
What might make this OT is that it's not a question specifically about
building LFS, but rather a question of a script that I use to build LFS
not working the way I want it to. If this is really OT, maybe someone
will respond privately if the any have any ideas.
As many of you know, I use the More Control with Package Users
management system. I have modified the build scripts in the hint to
minimize the pedantic work at the keyboard that's involved with a
build. The script is designed to find the tarball, un-tar it and the
configure, make,make check and install. Additionally, I add other
necessary commands from the book in the appropriate places; e.g.
patches, creating symlinks and moving files around.
The script has evolved over six years and, much to my chagrin right now,
I've not been good at keeping the old versions or maintaining a changelog.
One thing I want it to do is recover from a failed 'make' or 'install'
without have to run the whole script again. This feature *used to*
work. It now doesn't. If everything is OK, the script runs from the
beginning to the successful end of a build. But if there is a glitch,
the recovery doesn't happen.
The most common interruption in a build, when using more control, is
write permissions to a directory. This causes the 'install' to abort.
The fix is simple. Change the write permissions and re-run the script.
I want it to pick up with the make install command, but right now it
goes to the make command on any abort. I thing the testing for
conditions is failing, and I cannot see the flaw in the logic or
construction. It is in this area that I'd like some help. A fresh set
of eyes, so to speak.
Following is the script from the variable definition through the logic
tests. I've eliminated all the extra stuff.
#! /bin/bash
# Begin Build for PACKAGE
# Run this script from the package user's home directory by invoking it
# with the package name--ex. vim-7.2. ./build vim-7.2 or ./build
$(whoami) It will find
# the tarball in $PACKAGES, untar it, change to the created directory
# and configure, make, make check and make install. Then it will
clean up
# by creating a list of the installed files and remove the source tree.
# It will create 6 log files in the $HOME directory:
# configure.log: All messages output during configure
# configure.err: Just the errors output during configure
# make.log: All messages output during make
# make.err: Just the errors output during make
# install.log: All messages output during make install
# install.err: Just the errors output during make install
# variables
package=$@
logdir=$package-logs
PACKAGES=/sources
CURRENT=$package
took out a lot of stuff
# Begin tests and function calls for fresh and failed builds.
# This one recovers from failed make.
if [ -e $logdir/make-`echo $package`.err ] \
[ ! -e $logdir/install-`echo $package`.err ]; then #Now build
removed make, make check and make install sections
fi
# This one recovers from a failed install
if [ -e $logdir/make-`echo $package`.log ] \
[ ! -e $HOME/$package-files.list ]; then
removed make install section
fi
# This one does everything through configure, make, make install
if [ ! -e $logdir ]; then
removed configure, make, make check and make install sections
removed extra commands and clean up sections.
fi
# End Build
This script creates six logs: configure.{log,err}, make.{log,err} and
install.{log,err}, which I put in a log directory, $logdir. The very
last thing is does is create a list of files installed,
$package-files.list. Therefore, and here comes the testing logic, at
the beginning there is no log directory, and the test becomes [ ! -e
$logdir ].
The necessary and sufficient conditions to define a failed make are a
make log or configure log that exists and an install log or package file
list that does not exist. If an install fails, there will be a make
log but no file list. An install log *may* exist so I don't consider it
in the logic.
The preceding two paragraphs are my logic. Would someone please, using
that, compare the logic to the test statements to see if they match, if
the tests are constructed properly or if I need different logic.
As I said, if all is well, the script runs like a charm. If there's a
hiccup, a failed install, the script starts from the make test.
Doesn't that mean the the logic failed?
I've removed a lot of stuff in the script trying to make things relevant
and specific to only the question. Please feel free to ask for
additional info.
I'm hoping that someone can point me to better constructs or better logic.
Thanks,
Dan
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: Hopefully Someone Will Check and Comment on My Logic [OT Maybe?]
On Sat, 12 Mar 2011 18:00:56 -0600
Dan McGhee beesnee...@att.net wrote:
[snip]
Following is the script from the variable definition through the
logic tests. I've eliminated all the extra stuff.
[snip]
# This one recovers from a failed install
if [ -e $logdir/make-`echo $package`.log ] \
[ ! -e $HOME/$package-files.list ]; then
[snip]
I've removed a lot of stuff in the script trying to make things
relevant and specific to only the question. Please feel free to ask
for additional info.
[snip]
Well... DOES the script add all the logfiles it is supposed to add?
Are you /sure/? Have you checked?
The tests look kosher, as far as that matters, but I would turn my
attention to the creation of logfiles.
Other than that, my money is on the `echo $package` substitutions.
If ${package} has a space in it, that could break it.
You can fix this by doing ''[ -e ${logdir}/make-${package}.log ]''.
Take a small package (gzip?), and build it in such a way that it breaks
at various points, then inspect the relevant directories to see what is
there and what is not.
--
-Aleksandar Kuktin
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: Hopefully Someone Will Check and Comment on My Logic [OT Maybe?]
On 03/12/2011 06:47 PM, Aleksandar Kuktin wrote:
On Sat, 12 Mar 2011 18:00:56 -0600
Dan McGheebeesnee...@att.net wrote:
[snip]
Following is the script from the variable definition through the
logic tests. I've eliminated all the extra stuff.
[snip]
# This one recovers from a failed install
if [ -e $logdir/make-`echo $package`.log ] \
[ ! -e $HOME/$package-files.list ]; then
[snip]
I've removed a lot of stuff in the script trying to make things
relevant and specific to only the question. Please feel free to ask
for additional info.
[snip]
Thank you, Aleksandar.
Well... DOES the script add all the logfiles it is supposed to add?
Are you /sure/? Have you checked?
Yes, yes and yes.
The tests look kosher, as far as that matters, but I would turn my
attention to the creation of logfiles.
Other than that, my money is on the `echo $package` substitutions.
If ${package} has a space in it, that could break it.
You can fix this by doing ''[ -e ${logdir}/make-${package}.log ]''.
This is what I was hoping to hear--that the logic is sound,but that
there might be a problem in the construct. I've shied away from ( ) and
{} in $ xxx statements because I'm really shaky on what they mean. I've
also never seen the ' ' [ ] ' ' construct. I use the Advanced Bash
Scripting Guide as my reference. Thank you for your feedback. I'll play
with this.
Take a small package (gzip?), and build it in such a way that it breaks
at various points, then inspect the relevant directories to see what is
there and what is not.
I've done this with GDBM by adding `exit 1` at various points. The
results are as I have described in my first post.
I appreciate your input. We'll see what happens.
Dan
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: Hopefully Someone Will Check and Comment on My Logic [OT Maybe?]
On Saturday 12 March 2011 19:00:56 Dan McGhee wrote:
# This one recovers from failed make.
if [ -e $logdir/make-`echo $package`.err ] \
[ ! -e $logdir/install-`echo $package`.err ]; then #Now build
removed make, make check and make install sections
fi
# This one recovers from a failed install
if [ -e $logdir/make-`echo $package`.log ] \
[ ! -e $HOME/$package-files.list ]; then
Technically, you may be mixing metaphors with this syntax. Perhaps the syntax
is valid, but it isn't doing what you expect. Try:
if [ -e file_1 -a ! -e file_2 ]; then
commands
fi
# equivalent: if test -e $file_1 -a ! -e file_2; then
OR use:
[ -e file_1 ] [ ! -e file_2 ] {
commands;
}
# equivalent: test -e $file_1 test ! -e file_2 {
OR even use:
[ -e file_1 -a ! -e file_2 ] {
commands;
}
# equivalent: test -e file_1 -a ! -e file_2 {
Also, the syntax '-e $logdir/make-${package}.log' will eliminate a smidgeon
of complexity even though what you did is correct. Any time you aren't sure if
a shell var like $var will be, or is being, parsed correctly in context, put
the name in braces, as in ${var}.
Nothing else on your script pokes me in the eye with a sharp stick.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
