[lfs-support] vi for chapter 6
zarniwhoop at ntlworld.com
Wed Oct 3 16:00:58 PDT 2012
On Wed, Oct 03, 2012 at 04:42:18PM -0500, Bruce Dubbs wrote:
> Garrett Gaston wrote:
> > Last time I did the LFS project I had to write all my scripts for
> > chapter 6 from another shell from the host system. This time around
> > I'd like to go ahead and be able t write my chapter 6 scripts from
> > within the chroot environment. I'M currently in chapter 5, should I
> > be installing vi now or when I get to chapter 6?
> At the end of Chapter 5 installing in /tools will probably interfere the
> Personally though, I would just use another shell and edit
> -- Bruce
When I used cross-lfs, we used to install vim at the end of /tools
because in some situations the next step was to boot the new temp
system instead of entering chroot - I don't recall any problems with
that (but, if you want to do it, please take a look at whatever is
currently in clfs for vim in /tools). But for people who are
entering chroot it is much easier to use multiple terms/xterms.
In my own case, I build desktops using one desktop screen with four
xterms on it (rxvt-unicode for me, but xterm or any other 'x' term
should suffice) - 1 : my notes, 2: root, where I mounted /mnt/lfs -
also used to review my logs when the build hasn't reached less/view,
and occasionally for editing if things went wrong - TERM=xterm-color
is close to urxvt, but backspace still cateches me out :) 3: git for
my scripts [ /sources is an nfs mount from my server, and I put my
git tree for scripts there ] and 4: the build. For the server, when
I rebuild it, something similar but using ssh for root and the build.
Of course, if your desktop isn't going to let you put 4 separate
terms on the same desktop (e.g. - no, I'll not name an environment
here) then other ways may be easier.
Also, saving your scripts from one build to the next is often
useful - my own build used to be one long script for chapter5 and
another long script for chapter6, followed by perhaps 4 or 5 more
long scripts for my (then) limited desktop, but even then it was
much simpler to just make the changes than to start again from
scratch. Of course, upgrading LFS, particularly the toolchain,
usually means that changes are necessary in a few packages in BLFS
(e.g. more restrictive c++ rules, or perhaps changed kernel headers
impact strace or gdb).
Summary - do whatever works for you, but don't unnecessarily
reinvent what you have previously managed to adequately achieve
(*your* definition of adequately, of course).
das eine Mal als Tragödie, das andere Mal als Farce
More information about the lfs-support