n-roeser at gmx.net
Thu Sep 16 07:55:19 PDT 2004
-----BEGIN PGP SIGNED MESSAGE-----
Jan Mattila wrote:
> Quoting "Matthias B." <msbREMOVE-THIS at winterdrache.de>:
>> On Wed, 15 Sep 2004 15:56:49 -0600 (MDT) Scott Swanson
>> <DrMemory at starband.net> wrote:
>> > On Wed, 15 Sep 2004, Scott Swanson wrote:
>> > correction:
>> > + exec env -i HOME=/home/lfs TERM=linux 'PS1=\u:\w\$ ' /bin/bash
>> Is there a special reason why you placed the quotes different
>> from the command in the book? I don't think that could be
>> responsible for your problem, but you never know.
> Scott posted earlier (Sat Sep 11 08:55:20 MDT 2004), that he had
> exec...PS1='\u:\w\$ ' in his .bash_profile
> and when I tested the same set -x I also got 'PS1=\u:\w\$ '
> So maybe that's just something the set -x does? For me at least
> it had no effect on getting a prompt.
bash is causing that, and it is completely harmless.
Try the following:
export foobar='this text contains spaces'
set foobar='a space'
set foobar=a\ space
Take a minute to think about this: bash needs to pass the command line
parameters on to programs that are called. If one of them contains a
space, we use quotes to make clear that it still is one argument (we
may also use a backslash to escape that space). bash will pass the
argument on *without* the quotes or a backslash etc. If we did a 'set
- -x' before, bash must tell us what it's actually doing, but a human
user would not be able to interpret the output correctly if there were
no quotes in it (if there are spaces inside at least one of the
arguments). So bash quotes every single argument that is passed to the
program, if necessary.
I haven't checked on this, but this *should* be documented somewhere
(perhaps hidden under a rock, and in extreme techie-speak) in the bash
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
-----END PGP SIGNATURE-----
More information about the lfs-support