nohup feature request / Please fwd to Jim Meyering
Dear Jim I use nohup (ubuntu linux), and I have a feature request. Often I run more than one program at a time under nohup, and some of these programs run for at least a couple of hours. Every now and then nohup writes the output to nohup.out, which I find very useful. My request is: could the output be preceded by 1) the name/PID of the process that produces the output. 2) the time that the output was produced. Thanks! Jack van de Vossenberg ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: nohup feature request / Please fwd to Jim Meyering
Jack van de Vossenberg [EMAIL PROTECTED] writes: Dear Jim I use nohup (ubuntu linux), and I have a feature request. Often I run more than one program at a time under nohup, and some of these programs run for at least a couple of hours. Every now and then nohup writes the output to nohup.out, which I find very useful. nohup does not produce the output by itself, it's done directly by the executed command. In fact, nohup just sets up the signals and redirection and the replaces itself by directly executing the command. My request is: could the output be preceded by 1) the name/PID of the process that produces the output. 2) the time that the output was produced. There is no way to control the output after the command is executed. If you want to know which command produces which output redirect it manually to different files. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Simplifying command line parsing with Genparse
Hi, would it be an option to use Genparse (http://genparse.sourceforge.net/) for command line parsing in the GNU Coreutils? I'm one of the developers of Genparse and I recently used some of the well known Coreutils as an exercise for testing Genparse (see http://genparse.sourceforge.net/examples.html). Using Genparse for generating the command line parsing code could reduce the amount of coreutils source code because the input to Genparse is a short config file only. The overhead of writing the parser code would be delegated to the tool then. The Genparse generated parsers call getopt() (or getopt_long()) exactly the same way the Coreutils's command line parsers do it today. This wouldn't be changed. So the code Genparse generates will be very similar to the existing hand written parsers of the individual Coreutils tools. But calling getopt() is only part of the work, preparing and evaluating the results of getopt() also causes coding work which could be delegated to Genparse. Genparse also automatically generates a help screen which would no longer have to be done manually. Michael ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Simplifying command line parsing with Genparse
[EMAIL PROTECTED] (Michael Geng) wrote: would it be an option to use Genparse (http://genparse.sourceforge.net/) for command line parsing in the GNU Coreutils? I'm one of the developers of Genparse and I recently used some of the well known Coreutils as an exercise for testing Genparse (see http://genparse.sourceforge.net/examples.html). Using Genparse for generating the command line parsing code could reduce the amount of coreutils source code because the input to Genparse is a short config file only. The overhead of writing the parser code would be delegated to the tool then. The Genparse generated parsers call getopt() (or getopt_long()) exactly the same way the Coreutils's command line parsers do it today. This wouldn't be changed. So the code Genparse generates will be very similar to the existing hand written parsers of the individual Coreutils tools. But calling getopt() is only part of the work, preparing and evaluating the results of getopt() also causes coding work which could be delegated to Genparse. Genparse also automatically generates a help screen which would no longer have to be done manually. Hi Michael, Genparse looks promising. I like the examples. But there are almost 100 programs in the coreutils. If genparse can really handle all of those use cases without causing any significant degradation in the tools, then it will be hard to object. How does it deal with internationalization? However, before I even consider it seriously, it'll need some improvements: - it must detect any and all write failures[*] - packaging so that I can run ./configure make make check, and if I don't happen to have cppunit infrastructure, gcj or something similar, it should tell me about it directly, rather than causing harder-to-diagnose build failures. - one of the generated .c files I looked at calls strdup but doesn't check for a NULL return value or (less important) attempt to avoid the leak when the corresponding --backup=S option appears twice or more. - not exactly essential, but highly recommended: it should work with the latest autoconf and automake [*] with genparse-0.6.3, I get this: $ strace -o log -e write ./genparse -o /full/tmp/foo ../examples/ls.gp \ echo exit status 0 creating /full/tmp/foo.h...done creating /full/tmp/foo.c...done exit status 0 $ tail -2 log write(3, /***..., 80) = -1 ENOSPC (No space left on device) write(1, creating /full/tmp/foo.c...done\n, 32) = 32 The two files it claims to have created are both empty, and genparse exited successfully. This means genparse is not detecting write or close failures. Note that in the example above, /full/tmp is a full file system that still has free inodes, so open can create new files, but writes always fail. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Simplifying command line parsing with Genparse
Jim Meyering [EMAIL PROTECTED] writes: Genparse looks promising. I like the examples. But there are almost 100 programs in the coreutils. If genparse can really handle all of those use cases without causing any significant degradation in the tools, then it will be hard to object. There's also argp, which is part of glibc and also provided by gnulib. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Simplifying command line parsing with Genparse
Andreas Schwab [EMAIL PROTECTED] wrote: Jim Meyering [EMAIL PROTECTED] writes: Genparse looks promising. I like the examples. But there are almost 100 programs in the coreutils. If genparse can really handle all of those use cases without causing any significant degradation in the tools, then it will be hard to object. There's also argp, which is part of glibc and also provided by gnulib. Of course. And my If ... statement above applies equally well to it. If we ever find someone with enough motivation and perseverance to make one of those tools satisfy my requirements, maybe that will be a sufficiently compelling case to convert the coreutils. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
sort --debug
Perhaps add a --debug option, so users don't write mail like the below :-) Kindly add an example to the sort info pages of how to sort zip utils xdm x11 cron admin dpkg admin lilo admin menu admin on the second field. No, -k 2,2 2,2b or whatever doesn't work. Better yet, why don't you also add a --debug option, which outputs what sort thinks the fields are. Wait, sort -k 2b,2 worked! OK, but still add a --debug option. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Simplifying command line parsing with Genparse
On Thu, Jun 07, 2007 at 02:44:38PM +0200, Jim Meyering wrote: [EMAIL PROTECTED] (Michael Geng) wrote: would it be an option to use Genparse (http://genparse.sourceforge.net/) for command line parsing in the GNU Coreutils? I'm one of the developers of Genparse and I recently used some of the well known Coreutils as an exercise for testing Genparse (see http://genparse.sourceforge.net/examples.html). Using Genparse for generating the command line parsing code could reduce the amount of coreutils source code because the input to Genparse is a short config file only. The overhead of writing the parser code would be delegated to the tool then. The Genparse generated parsers call getopt() (or getopt_long()) exactly the same way the Coreutils's command line parsers do it today. This wouldn't be changed. So the code Genparse generates will be very similar to the existing hand written parsers of the individual Coreutils tools. But calling getopt() is only part of the work, preparing and evaluating the results of getopt() also causes coding work which could be delegated to Genparse. Genparse also automatically generates a help screen which would no longer have to be done manually. Hi Michael, Genparse looks promising. I like the examples. But there are almost 100 programs in the coreutils. If genparse can really handle all of those use cases without causing any significant degradation in the tools, then it will be hard to object. How does it deal with internationalization? There is no internationalization. I looked at the Coreutils internationalization but I neither fully understood how it works nor do I have an idea right now how to internationalize Genparse's output. internationalization appears to be a difficult thing. However, before I even consider it seriously, it'll need some improvements: I appreciate your concerns very much. All of them are valid and valuable input for Genparse development. At least some of them will need more discussion however which I think is not interesting to everybody listening to the Coreutils mailing list. For this reason I started a new thread on the genparse-users mailing list (http://sourceforge.net/mailarchive/forum.php?thread_name=20070607150633.GA26405%40t-online.deforum_name=genparse-users). Any posts to the genparse-users mailing list from anybody is welcome! I will let you (and the coreutils-bug mailing list) know if there is any progress on ony of the problems you listed. - it must detect any and all write failures[*] - packaging so that I can run ./configure make make check, and if I don't happen to have cppunit infrastructure, gcj or something similar, it should tell me about it directly, rather than causing harder-to-diagnose build failures. - one of the generated .c files I looked at calls strdup but doesn't check for a NULL return value or (less important) attempt to avoid the leak when the corresponding --backup=S option appears twice or more. - not exactly essential, but highly recommended: it should work with the latest autoconf and automake [*] with genparse-0.6.3, I get this: $ strace -o log -e write ./genparse -o /full/tmp/foo ../examples/ls.gp \ echo exit status 0 creating /full/tmp/foo.h...done creating /full/tmp/foo.c...done exit status 0 $ tail -2 log write(3, /***..., 80) = -1 ENOSPC (No space left on device) write(1, creating /full/tmp/foo.c...done\n, 32) = 32 The two files it claims to have created are both empty, and genparse exited successfully. This means genparse is not detecting write or close failures. Note that in the example above, /full/tmp is a full file system that still has free inodes, so open can create new files, but writes always fail. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: nohup feature request / Please fwd to Jim Meyering
Jack van de Vossenberg wrote: Dear Jim I use nohup (ubuntu linux), and I have a feature request. Often I run more than one program at a time under nohup, and some of these programs run for at least a couple of hours. Every now and then nohup writes the output to nohup.out, which I find very useful. My request is: could the output be preceded by 1) the name/PID of the process that produces the output. That's not possible unfortunately, as nohup just sets things up, and replaces itself with the command. It might suffice to have separate files for each command, which you can specify by using redirection: nohup nice command1 command1.out nohup nice command2 command2.out Personally I much prefer using screen to nohup: http://www.pixelbeat.org/docs/screen/ 2) the time that the output was produced. Hrm, if your command output was sufficiently terse, perhaps you could use the system logging facility for that? nohup nice command1 | logger Pádraig. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: nohup feature request / Please fwd to Jim Meyering
Pádraig Brady wrote: My request is: could the output be preceded by 1) the name/PID of the process that produces the output. That's not possible unfortunately, as nohup just sets things up, and replaces itself with the command. It might suffice to have separate files for each command, which you can specify by using redirection: Of course it is possible; nohup knows its pid as well as the command it is asked to run. When it opens the output file it just needs to use that information to name it. nohup nice command1 command1.out nohup nice command2 command2.out This works too. Personally I much prefer using screen to nohup: http://www.pixelbeat.org/docs/screen/ Screen is nice for interactive commands that you want to come back to later. For things that you just want to run in the background and forget about, I find the batch command to be very useful. Works similar to nohup but instead of having to check an output file for the results later and check ps to see if the command is still running, you get the results in an email when it is finished. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
SEQ BUG
Hi, I've the following behavior with the seq function on: Linux version 2.6.18.8-0.3-default ([EMAIL PROTECTED]) (gcc version 4.1.220061115 (prerelease) (SUSE Linux)) #1 $ echo `seq 0.0 0.1 0.8` 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 $ echo `seq 0.0 0.1 0.9` 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 Best regards, Patrick Amstutz ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: SEQ BUG
Patrick Amstutz wrote: Hi, I've the following behavior with the seq function on: Linux version 2.6.18.8-0.3-default ([EMAIL PROTECTED]) (gcc version 4.1.220061115 (prerelease) (SUSE Linux)) #1 $ echo `seq 0.0 0.1 0.8` 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 $ echo `seq 0.0 0.1 0.9` 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 Actually, not a bug. This behavior is described in the info manual (info seq or info coreutils seq), and has to do with the limitations of binary floating point types; look for the line starting Be careful when using `seq' with a fractional INCREMENT. You need to use something more like: $ echo `seq 0.0 0.1 0.91` 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: SEQ BUG
Patrick Amstutz scripsit: $ echo `seq 0.0 0.1 0.8` 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 $ echo `seq 0.0 0.1 0.9` 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 Welcome to floating-point roundoff errors. The decimal constant 0.1 cannot be exactly represented as a floating-point number on modern hardware, so 0.1+0.1+0.1+0.1+0.1+0.1+0.1+0.1+0.1 is actually greater than 0.9; consequently, 0.9 is not printed. You should never iterate using floating-point fractions for this reason. -- Where the wombat has walked,John Cowan [EMAIL PROTECTED] it will inevitably walk again. http://www.ccil.org/~cowan ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: SEQ BUG
Micah Cowan scripsit: You need to use something more like: $ echo `seq 0.0 0.1 0.91` 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 Or better yet, use `seq 0 9` and prepend the 0. part yourself. (The Cowan twins strike again!) -- A witness cannot give evidence of his John Cowan age unless he can remember being born. [EMAIL PROTECTED] --Judge Blagden http://www.ccil.org/~cowan ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: SEQ BUG
Micah Cowan wrote: Patrick Amstutz wrote: Hi, I've the following behavior with the seq function on: Linux version 2.6.18.8-0.3-default ([EMAIL PROTECTED]) (gcc version 4.1.220061115 (prerelease) (SUSE Linux)) #1 $ echo `seq 0.0 0.1 0.8` 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 $ echo `seq 0.0 0.1 0.9` 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 Actually, not a bug. This behavior is described in the info manual (info seq or info coreutils seq), and has to do with the limitations of binary floating point types; look for the line starting Be careful when using `seq' with a fractional INCREMENT. You need to use something more like: $ echo `seq 0.0 0.1 0.91` 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 The issue and work around are documented in the info page, but why don't we do the suggestion automatically in code (using the precision that is automatically worked out already)? Users of seq should not need to know about the specifics of floating point representations. Another thing I just noticed. I would expect the precision of all output in the following command to be to 2 decimal places not 1: $ seq 0.00 0.01 0.90 | grep \.[0-9]$ 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 Pádraig. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: SEQ BUG
Pádraig Brady wrote: Another thing I just noticed. I would expect the precision of all output in the following command to be to 2 decimal places not 1: $ seq 0.00 0.01 0.90 | grep \.[0-9]$ 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 I wouldn't. The documentation is fairly clear that the '%g' specifier is what gets used by default. If you want something else, you need to specify the format via the -f option; for example: $ seq -f %.2f 0.00 0.01 0.90| grep \.[0-9]0$ 0.00 0.10 0.20 0.30 0.40 0.50 0.60 0.70 0.80 0.90 In any case, I think John's advice is wisest: don't use floating point math for iteration. These are exactly the sorts of troubles you get when doing so. -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: nohup feature request / Please fwd to Jim Meyering
Phillip Susi wrote:
Pádraig Brady wrote:
That's not possible unfortunately, as nohup just
sets things up, and replaces itself with the command.
Of course it is possible; nohup knows its pid as well as the command it
is asked to run. When it opens the output file it just needs to use
that information to name it.
Well, perhaps in a sense *anything* is possible with enough code to
implement it. However as originally designed and currently written it
is not possible for nohup to do this. It is only possible for nohup
if it were rewritten to be a completely different program. It would
need to be an active participant in the I/O. And I would hate to
invalidate all of the Unix documentation written to date on nohup.
But I don't think that is needed. For active participation in the I/O
I would suggest one of the scripting languages.
Example:
ruby -le 'IO.popen(foo).each_line { |l| puts l.sub(/^/,foo: ) }'
Also note that if the program 'foo' buffers output then programs
processing it won't get the output as it happens but instead would get
it in larger chunks as the buffers are flushed out.
Bob
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: SEQ BUG
Pádraig Brady [EMAIL PROTECTED] wrote: ... Another thing I just noticed. I would expect the precision of all output in the following command to be to 2 decimal places not 1: $ seq 0.00 0.01 0.90 | grep \.[0-9]$ 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 Well, at least with the very latest from coreutils and libc6-2.5-10 from Debian unstable, I get what you (and I) would expect: $ seq 0.00 0.01 0.90 | grep '\.[0-9]$' $ However, with ubuntu's 2.5-0ubuntu14, I do see the same offending behavior you quote above. Sounds like another good argument for switching to a consistent printf implementation. I'm expecting to switch to gnulib's pretty soon, in any case. If that doesn't help, then at least we'll have a convenient mechanism to correct the behavior. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Simplifying command line parsing with Genparse
Michael Geng wrote: I would expect Genparse to generate faster code than argp because it does part of the work at compile time while argp does everything at run time since it's a library function. Is the performance of parsing program arguments really a concern? I would think that the difference would not be significant. I would value clean code over minor performance improvements. For coreutils I would value object code size over performance. Bob ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: SEQ BUG
Pádraig Brady scripsit: The issue and work around are documented in the info page, but why don't we do the suggestion automatically in code (using the precision that is automatically worked out already)? That implies using either a fixed-point or a decimal-based floating-point package. GNU gmp seems to be the obvious candidate. -- Knowledge studies others / Wisdom is self-known; John Cowan Muscle masters brothers / Self-mastery is bone; [EMAIL PROTECTED] Content need never borrow / Ambition wanders blind; http://ccil.org/~cowan Vitality cleaves to the marrow / Leaving death behind.--Tao 33 (Bynner) ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
