On Tue, Jun 05, 2007 at 02:21:33PM +0200, Jim Meyering wrote:
> 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
Well, I'll prepare a new version.
> 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 :)
Yes, it should be a binary.
> 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.
Ah... I see, "modesty & brevity" :-)
Karel
--
Karel Zak <kzak@xxxxxxxxxx>
-
To unsubscribe from this list: send the line "unsubscribe util-linux-ng" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
