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 > . Goodness! I'm using ubuntu as my host system. Hope tar works! > >> 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 and . 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 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, albei
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 . > > 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
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 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 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 p
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 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
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 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 11:56 AM, Pierre Labastie wrote: > Le 12/10/2013 18:27, Dan McGhee a écrit : >> >> Here is the line in question: >> >> cd "$HOME/xxxbuild/yyysrc" && srcdir="$(pwd)" || exit 1 >> >> >> >> "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 ]. >> >> > Well, dunno if this is rant, recommandation or comment, but you should have a > look > at the paragraph about "Lists" in the bash manpage. > It's all explained there, much better than I would. > > But now a rough answer: the meaning of this line is: > change directory to ${HOME}/blah. If that succeeds, set the srcdir variable > to the > full path to that directory. If either of the preceding commands fails then > exit with error code. > > Regards > Pierre Thanks, Pierre. 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 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. I read the bash man page about Lists. Thanks for pointing that out. I'm thinking that the syntax I was thinking of was for running tests. And the plain language translation that you used is very close to my own. But let's take translation apart list by list and operator by operator. I'm going to be very pedantic and put in the bash man page words using what's above rather than command{1,2}. is executed if and only if cd "$HOME/blah" returns an exit status of zero. (The exit status of .) Now, will be executed if and only if the exit status of is non-zero. And since the exit status of the list depends on the status of the last command executed it will always be zero. Therefore, <|| exit 1> becomes irrelevant because of the existence of $HOME/blah. I don't know if gedit is "smart enough" to pick up errors in logic or not, but it tells me that something is not right. The quotation marks, "", also have my attention. I know that different script writers do things differently. I use them only when syntax requires it or when talking about an array. Maybe it's me who's ranting. :) I'm also thinking in terms of testing and maybe I should just look at the commands themselves. 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: [lfs-support] Possible Syntax Error in Current "Package User" Hint Build Script
Le 12/10/2013 18:27, Dan McGhee a écrit : > 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 Well, dunno if this is rant, recommandation or comment, but you should have a look at the paragraph about "Lists" in the bash manpage. It's all explained there, much better than I would. But now a rough answer: the meaning of this line is: change directory to ${HOME}/blah. If that succeeds, set the srcdir variable to the full path to that directory. If either of the preceding commands fails then exit with error code. Regards Pierre -- 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] 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