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