Re: [lfs-support] A bug in gawk?
alex lupu wrote:
Bruce wrote:
See if awk 'BEGIN {FS=\\.so}... works for you.
Hi Bruce,
It DOES !!!
Thank you very much!
As an aside, (to explain) why _I_ prefer 'awk' to 'sed' _in this case:
for f in `cat tempx.txt`; do echo $f | sed -r 's/(.*)\.so.*/\1/'; done
vs.
cat tempx.txt | awk 'BEGIN {FS=\\.so} ; {print $1}'
awk is very powerful, but generally useful in more complex cases. It
also has a bit more overhead than sed. If I can do it in one line with
sed, that is my preference.
Come to think of it, I generally will use php instead of awk for those
more complex needs. That's much more powerful and the code is easier to
understand.
-- Bruce
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
[lfs-support] Possible Syntax Error in Current Package User Hint Build Script
I'm melding my build script to the current one from this hint. I've found a possible syntax error and want to see if my thinking is correct. Since I've been monitoring this list closely again, i.e.; the last three weeks, I've not seen anyone who has had a problem running this script. But I think that few people build this way. :) Here is the line in question: cd $HOME/xxxbuild/yyysrc srcdir=$(pwd) || exit 1 This patter occurs a number of times in the script and, therefore, I think it's important. For this question the references to what actually exist are not relevant. It's only the syntax. In attempting to understand what this statement is doing, I've come up with this plain language interpretation. Change to the package build directory IF AND ONLY IF the package source directory is the same as the current directory OR exit with a status of 1. In typing this I've also generated a question about the 's, but it's the use of the logical operators, which I've capitalized, that has my attention. Here's the question: If and || are logical operators, shouldn't the whole command be enclosed in double brackets, [[ command1 command2 || command3 ]]? The other syntax I know would be [ command1 -a command2 -o command3 ]. Of course, this is all predicated on the use of and || as logical operators. But if they're not, I don't understand the command. Comments? Answers? Recommendations? Rants? Thanks, Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Possible Syntax Error in Current Package User Hint Build Script
On Sat, Oct 12, 2013 at 01:36:04PM -0500, Dan McGhee wrote:
I suppose that the most practical thing for me to do is jump into Ch.
6 and build with the script in the hint as it exists now. I could
pause at the end of this command to see what was happening. However,
in a previous life I was an engineer (Oh, no!!) and my OCD has kicked
in. First of all, I want to understand everything the script is doing
and when I looked at it in my text editor (gedit in Ubuntu) I saw a
problem. With that editor the only valid thing in pick is what's
between two quotes in an echo command. Anything else in pink has
something wrong in front of it--a syntax error. In gedit everything in
the script after $(pwd) is pink. There's something wrong, and I'd
like to find it before I start.
Maybe the syntax highlighting in that version of gedit is missing
or broken. Try vim and see how it looks ('syntax on' in ~/.vimrc or
/etc/vimrc). I use a black background, with ':colorscheme elflord'
I didn't see anything unusual when I pasted that line into a script.
Not that vim's highlighting is perfect, it occasionally gets
confused but usually only when I scroll a long way through a long
script.
It's also, of course, possible that there is an apparent error
_before_ this which makes the highlighter confused.
ĸen
--
das eine Mal als Tragödie, dieses Mal als Farce
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: [lfs-support] Possible Syntax Error in Current Package User Hint Build Script
On 10/12/2013 03:01 PM, Ken Moffat wrote:
On Sat, Oct 12, 2013 at 01:36:04PM -0500, Dan McGhee wrote:
I suppose that the most practical thing for me to do is jump into Ch.
6 and build with the script in the hint as it exists now. I could
pause at the end of this command to see what was happening. However,
in a previous life I was an engineer (Oh, no!!) and my OCD has kicked
in. First of all, I want to understand everything the script is doing
and when I looked at it in my text editor (gedit in Ubuntu) I saw a
problem. With that editor the only valid thing in pick is what's
between two quotes in an echo command. Anything else in pink has
something wrong in front of it--a syntax error. In gedit everything in
the script after $(pwd) is pink. There's something wrong, and I'd
like to find it before I start.
Maybe the syntax highlighting in that version of gedit is missing
or broken. Try vim and see how it looks ('syntax on' in ~/.vimrc or
/etc/vimrc). I use a black background, with ':colorscheme elflord'
I didn't see anything unusual when I pasted that line into a script.
Not that vim's highlighting is perfect, it occasionally gets
confused but usually only when I scroll a long way through a long
script.
That was one of my first thoughts and so I loaded up a script that I
knew worked and looked at it. It was fine. BTW it was the build script
you helped me with a few years ago. You taught me how to extract the
package name from a tar archive not knowing what the final extender
was--gz, tz, bz, bz2. If you're interested, I've got that down to one
line now instead of four since tar -xf works for all the stuff that I've
tested.
It's also, of course, possible that there is an apparent error
_before_ this which makes the highlighter confused.
That was another one of my first thoughts--of course that begs the
question of how many _first_ thoughts can there be. But I'll be
hornswaggled if I can find anything.
The package users hint now uses a build.conf file to input the specific
commands from the book for each package. The line in question first
appears in a function call to add patches if required. Let me repeat
the whole call for clarity.
-patch)
cd $HOME/xxxbuild/yyysrc srcdir=$(pwd) || exit 1.
patch_commands # no logging for patch necessary
#test_pipe
;;
Everything just changed! I had a moment of clarity. I can't believe it.
My thought was, If there's something wrong in that line, the cd...
line, then if I edit it, I might get all the pretty colors back in the
rest of the script. The offensive character I found when I removed it
is the following $(pwd). When I remove the gedit indicates that the
syntax is OK. The problem, and it's not really a problem, is that this
exact line is the first in every function call of the script for _make),
_check) and _install). I understand the command because it puts you in
the right directory to run ./configure, make and install.
When I first saw this line, I thought that the purpose of all the was
to keep the shell from expanding things execpt a few special
characters. As a matter of fact, after I did some more editing just
know, I discovered that it's the combination of () and with $pwd that
causes the problem. Either set of characters *used alone* works. In
combination everything after ...d) including the is pink in gedit. I
know that last was a highly technical statement of the analysis. :)
I wonder if the first escapes the first ( and the last is seen as an
unresolved quote. Well, at least I found the problem, even though the
syntax sin escapes me--no pun intended, but when I read it, it's not a
bad one.
The script has been recently edited. I don't know how recently tested.
Hopefully, we can get the situation corrected.
Thanks again, Ken.
Dan
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: [lfs-support] Possible Syntax Error in Current Package User Hint Build Script
Hi Dan,
$(...) executes the command within the brackets. It is the same as
having `pwd` (they are backticks).
The reason for the double quotes around the $(pwd) is in case the
current directory name has spaces in it (or anything that is contained
in the $IFS variable to be exact - IFS=the internal field separator).
logically, that line could be written as
if cd $HOME/xxxbuild/yyysrc
then
srcdir=$(pwd)
else
exit 1
fi
hope this clarifies a little more and doesn't cause even more confusion.
regards
Chris
On 12 October 2013 22:59, Dan McGhee beesn...@grm.net wrote:
On 10/12/2013 03:01 PM, Ken Moffat wrote:
On Sat, Oct 12, 2013 at 01:36:04PM -0500, Dan McGhee wrote:
I suppose that the most practical thing for me to do is jump into Ch.
6 and build with the script in the hint as it exists now. I could
pause at the end of this command to see what was happening. However,
in a previous life I was an engineer (Oh, no!!) and my OCD has kicked
in. First of all, I want to understand everything the script is doing
and when I looked at it in my text editor (gedit in Ubuntu) I saw a
problem. With that editor the only valid thing in pick is what's
between two quotes in an echo command. Anything else in pink has
something wrong in front of it--a syntax error. In gedit everything in
the script after $(pwd) is pink. There's something wrong, and I'd
like to find it before I start.
Maybe the syntax highlighting in that version of gedit is missing
or broken. Try vim and see how it looks ('syntax on' in ~/.vimrc or
/etc/vimrc). I use a black background, with ':colorscheme elflord'
I didn't see anything unusual when I pasted that line into a script.
Not that vim's highlighting is perfect, it occasionally gets
confused but usually only when I scroll a long way through a long
script.
That was one of my first thoughts and so I loaded up a script that I
knew worked and looked at it. It was fine. BTW it was the build script
you helped me with a few years ago. You taught me how to extract the
package name from a tar archive not knowing what the final extender
was--gz, tz, bz, bz2. If you're interested, I've got that down to one
line now instead of four since tar -xf works for all the stuff that I've
tested.
It's also, of course, possible that there is an apparent error
_before_ this which makes the highlighter confused.
That was another one of my first thoughts--of course that begs the
question of how many _first_ thoughts can there be. But I'll be
hornswaggled if I can find anything.
The package users hint now uses a build.conf file to input the specific
commands from the book for each package. The line in question first
appears in a function call to add patches if required. Let me repeat
the whole call for clarity.
-patch)
cd $HOME/xxxbuild/yyysrc srcdir=$(pwd) || exit 1.
patch_commands # no logging for patch necessary
#test_pipe
;;
Everything just changed! I had a moment of clarity. I can't believe it.
My thought was, If there's something wrong in that line, the cd...
line, then if I edit it, I might get all the pretty colors back in the
rest of the script. The offensive character I found when I removed it
is the following $(pwd). When I remove the gedit indicates that the
syntax is OK. The problem, and it's not really a problem, is that this
exact line is the first in every function call of the script for _make),
_check) and _install). I understand the command because it puts you in
the right directory to run ./configure, make and install.
When I first saw this line, I thought that the purpose of all the was
to keep the shell from expanding things execpt a few special
characters. As a matter of fact, after I did some more editing just
know, I discovered that it's the combination of () and with $pwd that
causes the problem. Either set of characters *used alone* works. In
combination everything after ...d) including the is pink in gedit. I
know that last was a highly technical statement of the analysis. :)
I wonder if the first escapes the first ( and the last is seen as an
unresolved quote. Well, at least I found the problem, even though the
syntax sin escapes me--no pun intended, but when I read it, it's not a
bad one.
The script has been recently edited. I don't know how recently tested.
Hopefully, we can get the situation corrected.
Thanks again, Ken.
Dan
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
--
_ o , ,
/ | | |_| / \_/ \_| |
\__/ \/ \/ |/ \/ \/ \/|/
(|
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: [lfs-support] Possible Syntax Error in Current Package User Hint Build Script
On Sat, Oct 12, 2013 at 04:59:04PM -0500, Dan McGhee wrote:
On 10/12/2013 03:01 PM, Ken Moffat wrote:
Maybe the syntax highlighting in that version of gedit is missing
or broken. Try vim and see how it looks ('syntax on' in ~/.vimrc or
/etc/vimrc). I use a black background, with ':colorscheme elflord'
I didn't see anything unusual when I pasted that line into a script.
Not that vim's highlighting is perfect, it occasionally gets
confused but usually only when I scroll a long way through a long
script.
That was one of my first thoughts and so I loaded up a script that I
knew worked and looked at it. It was fine. BTW it was the build script
you helped me with a few years ago. You taught me how to extract the
package name from a tar archive not knowing what the final extender
was--gz, tz, bz, bz2. If you're interested, I've got that down to one
line now instead of four since tar -xf works for all the stuff that I've
tested.
Yeah - I think I've still got that in my functions. As you say, it
hasn't been needed for a few years. The problem is knowing when the
last system with an old version of tar has gone. I know, I'll claim
I'm retaining it in case I ever have to build from a debian system
joke/.
My thought was, If there's something wrong in that line, the cd...
line, then if I edit it, I might get all the pretty colors back in the
rest of the script. The offensive character I found when I removed it
is the following $(pwd). When I remove the gedit indicates that the
syntax is OK. The problem, and it's not really a problem, is that this
exact line is the first in every function call of the script for _make),
_check) and _install). I understand the command because it puts you in
the right directory to run ./configure, make and install.
When I first saw this line, I thought that the purpose of all the was
to keep the shell from expanding things execpt a few special
characters. As a matter of fact, after I did some more editing just
know, I discovered that it's the combination of () and with $pwd that
causes the problem. Either set of characters *used alone* works. In
combination everything after ...d) including the is pink in gedit. I
know that last was a highly technical statement of the analysis. :)
I wonder if the first escapes the first ( and the last is seen as an
unresolved quote. Well, at least I found the problem, even though the
syntax sin escapes me--no pun intended, but when I read it, it's not a
bad one.
The script has been recently edited. I don't know how recently tested.
Hopefully, we can get the situation corrected.
Parentheses can be a pain. In metaflac all tag values are input in
double-quoted strings, but I've never managed to get parentheses in
a tag - I did once manage \( which wasn't at all what I wanted, but
every other attempt got an error report from bash.
Similarly, a parenthesised subshell which is commented by # in a
here document (e.g. the command to get the libxul sdk in firefox's
mozconfig in the BLFS book) *is* evaluated by bash - took me a long
while to work out where the message :
Package libxul was not found in the pkg-config search path.
Perhaps you should add the directory containing `libxul.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libxul' found
was coming from when I built firefox without xulrunner :)
But it's all about learning.
ĸen
--
das eine Mal als Tragödie, dieses Mal als Farce
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: [lfs-support] Possible Syntax Error in Current Package User Hint Build Script
On 10/12/2013 05:48 PM, Ken Moffat wrote:
On Sat, Oct 12, 2013 at 04:59:04PM -0500, Dan McGhee wrote:
On 10/12/2013 03:01 PM, Ken Moffat wrote:
Maybe the syntax highlighting in that version of gedit is missing
or broken. Try vim and see how it looks ('syntax on' in ~/.vimrc or
/etc/vimrc). I use a black background, with ':colorscheme elflord'
I didn't see anything unusual when I pasted that line into a script.
Not that vim's highlighting is perfect, it occasionally gets
confused but usually only when I scroll a long way through a long
script.
That was one of my first thoughts and so I loaded up a script that I
knew worked and looked at it. It was fine. BTW it was the build script
you helped me with a few years ago. You taught me how to extract the
package name from a tar archive not knowing what the final extender
was--gz, tz, bz, bz2. If you're interested, I've got that down to one
line now instead of four since tar -xf works for all the stuff that I've
tested.
Yeah - I think I've still got that in my functions. As you say, it
hasn't been needed for a few years. The problem is knowing when the
last system with an old version of tar has gone. I know, I'll claim
I'm retaining it in case I ever have to build from a debian system
joke/.
Goodness! I'm using ubuntu as my host system. Hope tar works! joke/ | joke
My thought was, If there's something wrong in that line, the cd...
line, then if I edit it, I might get all the pretty colors back in the
rest of the script. The offensive character I found when I removed it
is the following $(pwd). When I remove the gedit indicates that the
syntax is OK. The problem, and it's not really a problem, is that this
exact line is the first in every function call of the script for _make),
_check) and _install). I understand the command because it puts you in
the right directory to run ./configure, make and install.
When I first saw this line, I thought that the purpose of all the was
to keep the shell from expanding things execpt a few special
characters. As a matter of fact, after I did some more editing just
know, I discovered that it's the combination of () and with $pwd that
causes the problem. Either set of characters *used alone* works. In
combination everything after ...d) including the is pink in gedit. I
know that last was a highly technical statement of the analysis. :)
I wonder if the first escapes the first ( and the last is seen as an
unresolved quote. Well, at least I found the problem, even though the
syntax sin escapes me--no pun intended, but when I read it, it's not a
bad one.
The script has been recently edited. I don't know how recently tested.
Hopefully, we can get the situation corrected.
Parentheses can be a pain. In metaflac all tag values are input in
double-quoted strings, but I've never managed to get parentheses in
a tag - I did once manage \( which wasn't at all what I wanted, but
every other attempt got an error report from bash.
Similarly, a parenthesised subshell which is commented by # in a
here document (e.g. the command to get the libxul sdk in firefox's
mozconfig in the BLFS book) *is* evaluated by bash - took me a long
while to work out where the message :
Package libxul was not found in the pkg-config search path.
Perhaps you should add the directory containing `libxul.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libxul' found
was coming from when I built firefox without xulrunner :)
That's a real lesson. I know.
But it's all about learning.
Amen!! And it's the learning that has motivated me to ask my question.
Some of the people who have helped me on this may roll their eyes when
they read what I'm about to say. In my build script, I don't intend to
use the construction I asked about. My version successfully does what
this command indicates. I learned in the Navy, If it ain't broke,
don't fix it. I'm incorporating the new stuff in the package users
hint into my build script. Mine stops to review logs and recovers from
failed make and install. There are a lot of little, nit-picky and
naggy things in package users that will cause make and install to fail.
It's a real drag to start from scratch for these things. My script is
designed to make the process less frustrating. Rob Taylor has recently
done some work with wrappers and scripts to further reduce the frustration.
But it's the learning that motivated me to ask my question. I too have
had problems with parentheses. And just like your experience with
firefox, I like to learn what the _precise_ use of something is. For
example, many people will say that command1 command2 means run
command2 after command1. And that's generally how it works. The
precise meaning is run command2 if and only if command1 has an exit
status of 0. That's a real, albeit purely logical and subtle,
difference. I've had problems before when using the
