mark obsolete usage of fold

Glenn L. McGrath bug1 at
Sun Dec 11 08:29:04 UTC 2005

On Sun, 11 Dec 2005 00:30:11 -0600
Rob Landley <rob at> wrote:

> On Saturday 10 December 2005 16:53, Glenn L. McGrath wrote:
> > Attached is a patch sets a feature to allow 'fold -40' type arguments
> > to fail, this behaviour is obsolete even in susv2.
> >
> > Im sure some scripts (e.g. configure) are still using it, so its
> > usefull to support it.
> >
> > The patch doesnt change default behaviour. Its really just to start to
> > organise things so we can one day have a global setting to choose what
> > posix standard to compile to.
> 1) If you're going to do this kind of thing, could you please have a global 
> argument to disable nonstandard extensions?  (I'm trying to keep the amount 
> of configuration people have to do down to a dull roar.  Getting buried in 
> options doesn't help.  I'm thinking of adding things like CONFIG_NEEDS_PROC 
> and CONFIG_LONG_OPTIONS to 1.2, for example.)

Ive commit some changes, i added 2 config options to Build Options, One
for SuSv2, the other for pre SuSv2.

> 2) I'm trying to get 1.1 out by new year's.  Could this kind of change please 
> wait until January?  (See big long bug list posted a couple days ago.)

umm, woops, too late.

> 3) I really think we should pick one standard we care about, and try to 
> implement all of.  (Right now it's that Open Group thing that's on the web, 
> which is roughly susv3.)  Trying to distinguish between susv2 and susv3 is 
> just going to drive us _crazy_.

The files i just patched are some obvious ones, but we can also get
information about changes between SuSv2 and SuSv3 from coreutils or
maybe the Heirloom Project.

I think we need a compatability layer for when things break, e.g.
configure scripts still use the numeric arguments in head/tail i think.

We can try for the latests standard, but still have the old behaviour
to fall back on.

> 4) We now have if(ENABLE_BLAH) rather than #ifdef CONFIG_BLAH.  In 1.2 I'm 
> hoping to do a big switchover and cleanup (after documenting it and figuring 
> out what compiler versions competently handle dead code elimination).
> 5) My worries about standards compliance currently are about filling out the 
> test suite and making sure we implement everything we need to.  What's the 
> advantage of #ifdefing _out_ extensions that are still used?  (It's not 
> complexity savings if the code is still there.  What are the space savings?  
> When we have tiny little changes that save tiny little amounts of space, I 
> like to group them together under bigger config options.  I'm not _against_ 
> saving 5 bytes here and 5 bytes there, but someday I'd like to have somehting 
> like a CONFIG_NITPICK to hide all config options that save less than 100 
> bytes each.  :)

The advantage i see of being pedantic about the latest standard is that
it helps developers fix their scripts, standards are meaningless if
people dont/wont use them. The easier it is for people to move on to
the latest standard the quicker we can remove all the compatability
code. But that is a long term issue, not a short term one.

> 6) I can see the advantage of disabling things like gnu extensions when people 
> want to use our code to test standards compliance, but right now we don't 
> implement anything close to the whole standard yet so do we want to start 
> worrying about that now?

I guess those few cases are some obvious ones that had bugged me for a
while, they have obsolete in the standard for like four years...

I really think people who are using numeric arguments need to fix their
scripts so we can all move on.

The changes looked pretty safe to me, i.e. not likely to break
anything, and its something that has been talked about for a long time
i think, so figured why not do it now.

> > Its been a long time since i committed anything, i expect to be more
> > active in the future...
> Welcome back. :)



More information about the busybox mailing list