Re: sed _s_gnu_alternatives_ (Re: [rft] (g)awk substitution)

Rob Landley
2007-01-26T17:47:48Z

On Thursday 25 January 2007 4:18 pm, Oleg Verych wrote:

> > As I said, I'm not particularly interested in a more intrusive solution
> > solving a problem I haven't actually seen. I don't see any obvious reason
> > why it wouldn't work, and yes it would probably also solve my problem, but
> > I still don't see why you think it's "better" than the three byte fix.
>
> Ehhh. "I'm not guilty" issue. Well, fine ;)

"guilty"?

You attempted to hijack my simple observation ("awk is the standard name, gawk
is not") into an attempt to replace susv3 standard utilities with extra shell
script. This is a separate agenda, and I have _no_ idea why you think I'm
obligated to pursue it for you.

The motivation for my patch is taht circa 2.6.12 I didn't need gawk on my
system to build; the need for it cropped up fairly recently. This is A) an
artificial requirement, B) a regression, C) trivial to fix.

I could also teach busybox awk to be called as "gawk", but awk is the standard
name and gawk is not, and gawk can already be called as awk. The _clean_
thing to do is send a patch to get Linux to use the standard name, which I
did. This is the minimally intrusive change, and since gawk's install
creates an awk symlink it shouldn't affect any existing systems.

That's what I did. I am simply not interested in your attempts to do
something else, in hopes of fixing a problem I haven't seen and which I'm not
convinced actually exists.

> If your current system is IA-32, or you have access to one, would you
> like to test scripts/makelst for me, as i'm seeing `bc' there. But my
> system have not one, i would like to replace it with shell or awk or
> whatever. TIA.

According to Posix and SUSv3, a development environment can be expected to
have bc:
http://www.opengroup.org/onlinepubs/009695399/utilities/bc.html

Would you like to try the one in busybox?

The minimal development environment I can build a working system in is 7
packages: linux, gcc, binutils, make, busybox, uClibc, bash. This is not
theoretical: I have actually done this, and I was building systems under this
as far back as 2003. (I became busybox maintainer after spending 2 years
upgrading busybox to make this _work_. I started by rewriting sed. I didn't
_know_ sed at the time, but binutils ./configure used some rather advanced
sed scripts to build, so I fixed it. It works now.)

I'm using this to get a minimal native environment on non-x86 target
platforms, to minimize the amount of cross compiling I have to do when
bootstrapping a new platform. (I submitted an OLS tutorial proposal on this,
although I dunno if they're interested.)

Rob
--
"Perfection is reached, not when there is no longer anything to add, but
when there is no longer anything to take away." - Antoine de Saint-Exupery