'su lfs' dropping into the background

Alex Groenewoud alex at linuxfromscratch.org
Wed Jan 21 12:48:24 PST 2004


Bruce Dubbs wrote:
> Greg Schafer wrote:
> >On Mon, Jan 19, 2004 at 10:33:31PM +0100, Alex Groenewoud wrote:
> >>What a mess.  The -m flag to useradd doesn't just create the /home/lfs
> >>directory, but also populates it with all the files from /etc/skel.
> >>   
> >Yes, of course. So, your /etc/skel is a mess. I don't see how LFS can do
> >much about that.
> >
> I second that.

But but but...  If we cater for old and even for broken hosts, shouldn't
we also cater for hosts with a borken /etc/skel?

Well, taking up the -k hint from Bill, I wondered where to find a dir
that would be guaranteed to be empty, and tried:

root:~# useradd -s /bin/bash -m lfs -k /home/lfs

It worked, /home/lfs stayed empty.  Then I tried:

root:~# useradd -s /bin/bash -m lfs -k /hmhmhm

That worked too, and useradd doesn't complain about the non-existent
directory.
So I propose to add something like "-k /absent" or "-k /nosuch" to the
useradd command in the book, together with a little explanation.
Anyone who sees any drawbacks?

> .profile is never looked at if .bash_profile (or .bash_login) exists.  
> Its not a problem here.  What could be a problem is /etc/profile on the 
> host system.

I tried it with an empty /etc/profile: same result.  Nothing helped,
until I removed the "exec" word from .bash_profile.
The following .bash_profile works just fine:

env -i HOME=$HOME TERM=$TERM PS1='\u:\w$ ' /bin/bash; exit

This of course keeps an extra bash running, but that's a small price to
pay to work around a malfunctioning exec command, IMHO.

> I can't reproduce either.  Alex, what version of bash are you using?

lfs:~$ bash --version | head -1
GNU bash, version 2.04.0(1)-release (i386-suse-linux)

lfs:~$ env --version | head -1
env (GNU sh-utils) 2.0

Alex




More information about the lfs-dev mailing list