barry at hartford.uconn.edu barry at hartford.uconn.edu
Wed Dec 27 08:42:24 PST 2000

ken_i_m wrote:
> Hey Hey:
> I don't recall this one getting floated on the list.
> some_command >& err.txt
> Is this a macro or something? My RedHat starter system will redirect the
> screenfulls of output from make, for example, to a file that I can then
> glance through at my leisure. LFS ignores it.
> This does several things for me, documentation being the most important.
> Since I am back to work I can no longer "hold (any amount of) state" in my
> head. Everything I do must be self-documenting as I may not be able to get
> back to it for days and have only an hour or so when I do.
> I think, therefore, ken_i_m

according to the bash manual, >& and &> are simanticly equivalent...

try &> instead... I've had no problems with this on my system...

the bash manual (for bash 2.04) also states that &> is the preferred
method of redirection.  this indicates to me that >& may be deprecated,
but shouldn't be broken in 2.04 (in fact, I'm on a Red Hat 7.0 box right
now that is able to redirect with >&)... So the next question is... did
you compile this system with optimizations?  What level.  I've noticed a
particular system that I built an LFS system on had some strange goings
on after applying the optimizations.  Sometimes, with flaky hardware,
these can produce undesirable results at compile time.  perhaps try
recompiling bash with level -O2 rather than -O3... Also, pay some
special attention to the -mcpu and -march options.  The same basic rule
applies to them, even if you think your hardware is absolutely kosher.

Also, avoid experimental settings with hdparm.  I found out the hard way
what kind of fun these things can cause :).  I had one box that wouldn't
run any executable what wasn't on the command line after running hdparm
with -X66 on my linux box connected to a PDC20262 ATA66 card... All
kinds of fun :)...

good luck.

Unsubscribe: send email to lfs-discuss-request at linuxfromscratch.org
and put unsubscribe in the subject header of the message

More information about the lfs-dev mailing list