adding "arch" (aka uname -m) to the coreutils

[Jim Meyering]

Karel Zak <address@hidden> wrote:
>  Hi Jim,
>
> On Tue, Apr 03, 2007 at 12:23:32PM -0700, H. Peter Anvin wrote:
>> Karel Zak wrote:
>> >On Tue, Apr 03, 2007 at 05:56:49PM +0200, Matthias Koenig wrote:
>> >>Hi,
>> >>
>> >>I noticed that /bin/arch has been removed in release 2.13-pre1.
>> >>While this command is equivalent to uname -m, it is used by some
>> >>old scripts. Any chance to keep this for compatibility reasons?
>> >
>> > Good point.
>> >
>> > Yes, I'd like to keep it. It seems that many people (include me :-)
>> > use it. We (Red Hat) have tried to remove it from our distros, but
>> > without success. I think maintain this tiny tool is without any
>> > overhead.
>>
>> #!/bin/sh
>> exec /bin/uname -m
>>
>> Either that, or just make uname detect a link to "arch".
>
>  What do you think about this idea? Is it possible to add the "arch"
>  command emulation to the "uname" command in a next coreutils release?
>
>  Please, see the following patch. Note, the patch doesn't include any
>  change to build system -- I'm not sure if automatically create the
>  link (/bin/arch -> /bin/uname) is a good idea, because almost all
>  people use old util-linux with the arch binary.
>
>     Karel
...

[ see http://marc.info/?l=util-linux-ng&m=118104205801820&w=2
  for the patch ]

Hi Karel,

Adding "arch" to the coreutils looks like it would be sensible, but if
we go that route, it'll have to be done a little differently, since
(following the GCS), the behavior of a program in this package does
not change based on it name.  I.e., it'd have to be a separate binary,
or maybe even a script.

For an example of how to do this in coreutils with a binary,
look at ls.h, ls-dir.c and ls-vdir.c.  IMHO, for something
as fundamental as arch (seeing as how it's used in places like
config.guess), it should be a binary, and not a script, but if
you make a case for using a script, I'll keep an open mind :)

If you're interested in pursuing this, it'd be great if you could
put together a complete patch, including these:

    ChangeLog entries (see other "New program" entries, e.g. runcon)
    NEWS entry
    AUTHORS update (add your name next to "arch", if you do this)
    README update (add the new program name to the list)
    documentation update (both man/arch.x and coreutils.texi)
    new files, src/uname.h, uname-arch.c
    {man,src}/Makefile.am

and for extra credit, also add a test script named, say, tests/misc/arch
comparing its output with e.g., that from uname -m.  You can use
tests/sample-test as a template.

A good cross-check is to run "make distcheck".

If you do submit a patch, it makes it easier for me if you
generate it with a command like this:

    git-format-patch --stdout --signoff HEAD~1 > patch

after you've committed into a branch of the repo you
get from this command:

    git clone git://git.sv.gnu.org/coreutils

If that's all Greek to you, don't worry about it,
"cvs diff -u" output is still ok.

Jim