Karel Zak <[EMAIL PROTECTED]> 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 _______________________________________________ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
