Some improvements to the init.d/functions script

Dear List, here are some suggested alterations to 'functions' from the lfs bootscripts. None of these are functional changes, but should make the script clearer to people reading it, or maybe just less annoying to me... Just typos: Dimentions <- Dimensions Cursur <- Cursor unfor

Re: GCC-4.0.1

Ag Hatzim wrote these words on 08/14/05 08:25 CST: > No,my build was based on the cvn of 30 of July with some cosmetic changes by > me but nothing serious to affect the glibc built. > > I already saw that your problem started from Heimdal was overwritten the > glob.h which installed by glibc,but

Re: Cross-LFS 5.9. Glibc-2.3.5 (32 bit build on a 32 bit host)

On 8/13/05, Jim Gifford <[EMAIL PROTECTED]> wrote: > Actually I found two causes for that error during my testing. > 1 - --enable-languages=c,c++ will cause that error, don't understand why > though > 2 - When LFS_HOST and LFS_TARGET32 are the same. (Verified thanx to Matt > Darcy) Ahh, yes. I did

BLFS 6.1 Final?

I'm looking at bugzilla and see four bugs that need to be integrated into BLFS-6.1: 1519 Other programming tools 1520 Cracklib 1524 Update URLs 1529 PostgreSQL file ownership Is there anything else that needs to be done for a final 6.1? -- Bruce -- http://linuxfromscratch.org/mailman/listinfo

Coreutils binary locations

Hi folks, In chapter06/coreutils.html we state: "Move programs to the proper locations: mv /usr/bin/{[,basename,cat,chgrp,chmod,chown,cp,dd,df} /bin mv /usr/bin/{date,echo,false,head,hostname,install,ln} /bin mv /usr/bin/{ls,mkdir,mknod,mv,pwd,rm,rmdir,sync} /bin mv /usr/bin/{sleep,stty,test,

Re: Coreutils binary locations

Matthew Burgess wrote these words on 08/14/05 14:07 CST: > However, I'm only going to invest time in > this if someone can convince me of why we *need* to move 'test' and '[' > to /bin. They are both used in /etc/rc.d/init.d/functions? -- Randy rmlscsi: [GNU ld version 2.15.94.0.2 20041220]

Re: Coreutils binary locations

Matthew Burgess wrote: > That then leaves us with the following binaries that I can't see a need > to move from /usr/bin: > > [, basename, install, test, touch > > Does anyone know why we do so? '[' is an alias for 'test' and is only used by some shells that don't have them set as builtin. T

Re: Coreutils binary locations

Randy McMurchy wrote: Matthew Burgess wrote these words on 08/14/05 14:07 CST: However, I'm only going to invest time in this if someone can convince me of why we *need* to move 'test' and '[' to /bin. They are both used in /etc/rc.d/init.d/functions? That's a shell script (with the magic

Re: Coreutils binary locations

Matthew Burgess wrote: > It appears as though 'tcsh' doesn't, but how many alternative shells > should we even care about? Plus, tcsh is a C shell, not a Bourne shell. All the bootscripts are written for a Bourne shell, and will consequently fail horribly if run in csh or tcsh. ;-) So I don't t

Re: Coreutils binary locations

Matthew Burgess wrote: > Move programs that the bootscripts require to /bin: > > mv /usr/bin/{head,sleep} /bin" `head' does not belong in /bin IMHO. Red Hat and Debian both agree with me. Surely `sed' can provide the same functionality for the bootscripts. > That then leaves us with the followi

Re: Proposal: proactive search for autofoo bugs

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Alexander E. Patrakov wrote: > When adding a "version update" comment to Bugzilla, please also add the > output of the following checker script: > > ifnames `find . -name \*.c -o -name \*.h` | grep HAVE | \ > grep -v HAVE_CONFIG_H | cut -d " " -f

/bin/compress

Hi The /bin/compress symlink (pointing to gzip) was added to allow newer tar's auto-detection of compressed archives to work on `.Z' archives. This is technically incorrect IMHO. Now, if you type in: compress filename you end up with a filename with a `.gz' extension instead of the expected

Re: Some improvements to the init.d/functions script

Bernard Leak wrote: > Dear List, > here are some suggested alterations > to 'functions' from the lfs bootscripts. I'm working on bootscripts now. As for the other problems mentioned last week, I committed the pidofproc/statusproc changes tonight, but do we want to restore the

Re: Some improvements to the init.d/functions script

DJ Lucas wrote these words on 08/14/05 23:31 CST: > but do > we want to restore the old functionality of printing a warning when > something is not running in killproc? I believe we have three yes' so > far. Anyone have any preference for the way it is now? Gosh, it is a no-brainer DJ. Chalk m

Re: Coreutils binary locations

On 8/15/05, Matthew Burgess <[EMAIL PROTECTED]> wrote: > work. The ideal solution would be to figure out a way of getting the > test/udev-test.pl script to figure out whether it should call > /usr/bin/test or /bin/test. However, I'm only going to invest time in > this if someone can convince m

Re: Some improvements to the init.d/functions script

Randy McMurchy wrote: > DJ Lucas wrote these words on 08/14/05 23:31 CST: > > >> but do >>we want to restore the old functionality of printing a warning when >>something is not running in killproc? I believe we have three yes' so >>far. Anyone have any preference for the way it is now? > > >

Re: Some improvements to the init.d/functions script

DJ Lucas wrote these words on 08/14/05 23:47 CST: > Is that yes - I'd like to see a nice green '[ OK ]' when I stop an > already stopped process (the way it is now, which _is_ correct by the > exit status)? That sucks. > Or is that yes - I'd like to see a yellow 'Warning: not > running [

Bogus usage of gcc --print-file

Hi During the toolchain adjustments, LFS does stuff like this: gcc --print-file specs IMHO the usage is bogus because: 1) `--print-file' is undocumented (therefore could break anytime) 2) `--print-file' only works by pure good fortune. Don't believe me? Try this with a GCC-3.4.x: