Re: [PATCH] Command line parsing of wc with genparse
[EMAIL PROTECTED] (Michael Geng) wrote:
I released version 0.6.6 of genparse which supports
internationalization now. A link to the download page
and to the updated documentation can be accessed from
the genparse project page http://genparse.sourceforge.net/.
I also prepared a patch which demonstrates how genparse
could be used for parsing the command line arguments of
the wc command. The patch is relative to the coreutils version
6.9. In order to compile the coreutils after you applied
the patch you will need genparse version 0.6.6 in your path.
Does this approach appear reasonable to you? What else should
be improved on genparse?
I took a quick look only at the patch (not at the code genparse generates)
and spotted some minor problems:
+ if (cmdline.version)
+{
+ version_etc (stdout, program_name, GNU_PACKAGE, VERSION, AUTHORS,
Here, it should be PROGRAM_NAME, not program_name.
...
diff -u -N -r coreutils-6.9.orig/src/wc.gp coreutils-6.9/src/wc.gp
--- coreutils-6.9.orig/src/wc.gp 1970-01-01 01:00:00.0 +0100
+++ coreutils-6.9/src/wc.gp 2007-07-10 18:17:33.0 +0200
@@ -0,0 +1,24 @@
...
+Report bugs to [EMAIL PROTECTED].
+#usage_end
s/fileutils/coreutils/
or, perhaps better: PACKAGE_BUGREPORT
Did you ensure that wc still passes make check?
Make sure valgrind wc ... shows no leaks, too.
In particular, test that with the --files0-from=F option.
Is there any significant difference in performance (I doubt it) or binary size?
I suggest you also adapt a program that takes integer arguments.
Can genparse handle arguments of all different types, from int
through uintmax_t?
tail looks like a good candidate. It also had an optional argument:
--follow[={name|descriptor}]
There are quite a few programs in the coreutils that have unusual
argument-parsing constraints, so it's hard to point to a small subset
and say if you adapt just these few, then that should be proof enough.
I'm afraid that if you're interested in having coreutils convert, you'll
have to do most of the work, and then demonstrate that there's no
resulting regression (and presumably cleaner code).
For now, let's start with tail, and maybe ls if you're ambitious :)
Another detail:
IMHO, the contents of your wc.gp file should reside in wc.c.
Might as well leave it in a delimited comment in place of the usage
function you're eliminating, then have a makefile rule use sed or awk
to extract it into wc.gp.
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
in(link) command errors
To whom it may concern: I'm writing to inform you of what might be a bug within Fedora-Linux 5,6,7. The problem is that when you try to create links, the in command doesn't respond or work even though is listed within the /bin directory. When you which,ls,or file any other command within /bin, they work just fine, except for the in( link) command...I followed instructions from several fedora books which work in other flavors of Linux, except Fedora.Basically from /var/named as per my book, I was creating a link to: /var/named/chroot/var/named/home.local.zone like this: in -s /var/named/chroot/var/named/home.local.zone home.local.zone but it doesn't work in any of the versions of Fedora listed above. Can you please look into it when you have a chance!! I'll be looking forward to your responds!!! Thanks ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: in(link) command errors
On Sun, 15 Jul 2007, tech045 @hotmail wrote: I'm writing to inform you of what might be a bug within Fedora-Linux 5,6,7. The problem is that when you try to create links, the in command doesn't respond or work even though is listed within the /bin directory. You have a typo - the command is ln (ell enn), not in. Cheers, Phil ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH] Command line parsing of wc with genparse
On Mon, Jul 16, 2007 at 10:02:13AM +0200, Jim Meyering wrote:
[EMAIL PROTECTED] (Michael Geng) wrote:
I released version 0.6.6 of genparse which supports
internationalization now. A link to the download page
and to the updated documentation can be accessed from
the genparse project page http://genparse.sourceforge.net/.
I also prepared a patch which demonstrates how genparse
could be used for parsing the command line arguments of
the wc command. The patch is relative to the coreutils version
6.9. In order to compile the coreutils after you applied
the patch you will need genparse version 0.6.6 in your path.
Does this approach appear reasonable to you? What else should
be improved on genparse?
I took a quick look only at the patch (not at the code genparse generates)
and spotted some minor problems:
+ if (cmdline.version)
+{
+ version_etc (stdout, program_name, GNU_PACKAGE, VERSION, AUTHORS,
Here, it should be PROGRAM_NAME, not program_name.
...
diff -u -N -r coreutils-6.9.orig/src/wc.gp coreutils-6.9/src/wc.gp
--- coreutils-6.9.orig/src/wc.gp1970-01-01 01:00:00.0
+0100
+++ coreutils-6.9/src/wc.gp 2007-07-10 18:17:33.0 +0200
@@ -0,0 +1,24 @@
...
+Report bugs to [EMAIL PROTECTED].
+#usage_end
s/fileutils/coreutils/
or, perhaps better: PACKAGE_BUGREPORT
Did you ensure that wc still passes make check?
I did this now - and I found a bug: wc -l doesn't work because I didn't assign
the print_lines variable. That's not a bug in genparse but in my hand written
code in wc.c. But after fixing this make check still fails because the usage()
function doesn't print a proper PACKAGE_BUGREPORT as you also found.
Make sure valgrind wc ... shows no leaks, too.
In particular, test that with the --files0-from=F option.
Is there any significant difference in performance (I doubt it) or binary
size?
I suggest you also adapt a program that takes integer arguments.
Can genparse handle arguments of all different types, from int
through uintmax_t?
tail looks like a good candidate. It also had an optional argument:
--follow[={name|descriptor}]
There are quite a few programs in the coreutils that have unusual
argument-parsing constraints, so it's hard to point to a small subset
and say if you adapt just these few, then that should be proof enough.
I'm afraid that if you're interested in having coreutils convert, you'll
have to do most of the work, and then demonstrate that there's no
resulting regression (and presumably cleaner code).
For now, let's start with tail, and maybe ls if you're ambitious :)
Another detail:
IMHO, the contents of your wc.gp file should reside in wc.c.
Might as well leave it in a delimited comment in place of the usage
function you're eliminating, then have a makefile rule use sed or awk
to extract it into wc.gp.
I will need some time to think about all the issues you mentioned and
find solutions. I appreciate your constructive commments!
Michael
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Segment fault rm corrupt files
I am running Fedora Core 6: Linux regmac-fc6 2.6.20-1.2962.fc6 #1 SMP Tue Jun 19 18:24:12 EDT 2007 i686 i686 i386 GNU/Linux On a number of occasions, Konqueror has crashed and produced a file named something like: /tmp/kde-$USER/konqueror-crash-XX.log However, the file has an unknown type, size, and permissions. As part of the /etc/rc.sysinit file, I have a rm command of the form: rm -rf /tmp/kde-$USER/* Because the type of these crash files are unknown, the rm command fails with a segment fault on my Intel IA86 machine (a MacBook running Parallels Fedora Core 6 Linux under Mac OS X (10.4)). In trying to solved this problem, I had run fsck a number of times, with no complaint from the fsck utility, even though the above mentioned files had invalid type(s). Any attempt to mv or cp fhese file raised fstat errors. Reg. Charney ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Segment fault rm corrupt files
Reg. Charney wrote: On a number of occasions, Konqueror has crashed and produced a file named something like: /tmp/kde-$USER/konqueror-crash-XX.log However, the file has an unknown type, size, and permissions. This makes no sense in the context of Unix filesystems. Please run the following command and post the output to the mailing list. You may need to adjust the file globs to match. ls -ld /tmp/kde-* /tmp/kde-*/konqueror-crash-*.log That will show us the file type, size and permissions. Or it will have an error which will also be informative. As part of the /etc/rc.sysinit file, I have a rm command of the form: rm -rf /tmp/kde-$USER/* Typically systems will purge the contents of /tmp on a reboot. I think Fedora does this but can't check at the moment. In which case the above command is not needed. Regardless of that the $USER is an environment variable. Inside of the /etc/rc.sysinit script that will almost certainly be root. I don't think this will match the user that was actually running konqueror at the moment that the core file was created. Therefore it will be very unlikely to actually match any files. Because the type of these crash files are unknown, the rm command fails with a segment fault on my Intel IA86 machine (a MacBook running Parallels Fedora Core 6 Linux under Mac OS X (10.4)). It would be good if you could show us the exact output. Bob ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
