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
