Verifiying commands entered

Ken Moffat ken at linuxfromscratch.org
Thu Oct 19 06:46:00 PDT 2006


On Thu, Oct 19, 2006 at 02:40:20PM +0200, Matt.Koll at t-online.de wrote:
>     Hi,
> I am building with the LiveCD and have made it to Chapter 5.11.1 GCC
> build Phase 2.
> I am at the point of running the commands for the fixinclude scripts.
> I have entered it as provided in the book, but would like to check that
> the command was actually successful.
> I am worried as I do see the message of the successful copy (the first
> command) but I am confused as to why Makefile.in at the end is still
> showing a date and time way back in the past.
> 
> Or am I mistaken in thinking that the way the file is modified should be
> reflected in the date and time indicating when the file was last
> touched?
> 
 I too would expect to see the updated time, but I've never looked
at the data and time here, so I might be missing something.

 First test: look at your command history ('history', or just
up-arrow) - did you key the command correctly ?

 Second test: diff Makefile.in{,.tmp}  - are they different ?

> I am also concerned as I had entered in chap 5.7 the litte verficiation
> test with dummy.c, at which end I did get no response. Then I checked
> the SPECFILE and realised that the change supposed to go in was not
> there. i.e. the link to the dynamic linker was not /tools/lib..... but
> still /lib..... After altering this by hand, the test worked as
> expected.
> I am still trying to work out why this part of the command did not work,
> as I did not get any message indicating an unsuccesful execution.

 Probably, you mis-keyed something (again, check the history if
still available).  I'm glad the check caught the problem.
> 
> Any hint towards documentaiton that may help me or a little indication
> on how I can verify the successful execution of the (or a ) command will
> be appreciated.
> 
> Thanks,
> Matt
> 
 That's difficult - some commands will report errors, others will
quietly end with a non-zero status [ echo $?  to check that ] and
some tend not to tell you - I'm thinking particularly of sed: error
messages from it mean syntax errors or missing files, they don't
tell you whether or not anything was changed.  So, it's easy to
mistype a sed command and either change nothing, or change the wrong
thing.  If you know what a sed is supposed to do, in early chapter 5
diff will tell you what got changed (later on, we can do in-place
seds, so diff won't help you wiht those).

Ken
-- 
das eine Mal als Tragödie, das andere Mal als Farce



More information about the lfs-support mailing list