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
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
On 6/7/07, Andreas Schwab <[EMAIL PROTECTED]> wrote: > 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. As andreas points out, nohup isn't in the I/O path there and hence can't do it. You can do something similar to this with the "logtstamp" configuration option of GNU screen, and you might also want to investigate the "batch" command. James. ___ 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
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: nohup feature request / Please fwd to Jim Meyering
Bob Proulx wrote: 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. It has no need to be an active participant in the IO; it just needs to change the name it passes to open() when it sets up the file descriptors prior to exec(). ___ 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: > Bob Proulx wrote: > > It would need to be an active participant in the I/O. > > It has no need to be an active participant in the IO; it just needs to > change the name it passes to open() when it sets up the file descriptors > prior to exec(). Uhm... I think we drifted from the feature discussion: Jack van de Vossenberg wrote: > 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. I don't think that is possible without an active participation by a process. Bob ___ 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
Bob Proulx scripsit: > > 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. > > I don't think that is possible without an active participation by a > process. Indeed, I don't see how it's possible at all. If nohup were to run its program using a pipe to intercept standard output and error, it wouldn't be able to tell child output from grandchild output. Data in a pipe is not tagged with its originator in any way. -- In politics, obedience and support John Cowan <[EMAIL PROTECTED]> are the same thing. --Hannah Arendthttp://www.ccil.org/~cowan ___ 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
Bob Proulx wrote: Uhm... I think we drifted from the feature discussion: How so? Jack van de Vossenberg wrote: 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. I don't think that is possible without an active participation by a process. What requires any kind of active participation? The only thing requested is that nohup open a file named with the current time and pid instead of /dev/null prior to exec()ing the given command. ___ 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: > Bob Proulx wrote: > > Jack van de Vossenberg wrote: > > > 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. > > > > I don't think that is possible without an active participation by a > > process. > > What requires any kind of active participation? The only thing > requested is that nohup open a file named with the current time and pid > instead of /dev/null prior to exec()ing the given command. Please read the feature request again. I believe you misunderstood it. Your reading of it and my reading of it are completely different. By the responses from the others I don't think I am alone here. There is no request there to open the file with the name/pid encoded in the file name. The request is to precede the output with the name/pid of the process, to precede the output with a timestamp. NOT this: $* >>nohup.out.$name-$pid But this: $* | sed "s/^/$name-$pid: /" >> nohup.out $* | sed "s/^/$timestamp: /" >> nohup.out Although in spirit I know the request was for some way to identify where the output came from and alternatives would probably be fine. But just the same that would be different. If I were asking for one but got the other I would be completely flabbergasted that the mark had been missed by that large of an amount. And let's not forget that the entire original V7 version of nohup was this next bit. This is not a snippet. This is the entire file! trap "" 1 15 if test -t 2>&1 ; then echo "Sending output to 'nohup.out'" exec nice -5 $* >>nohup.out 2>&1 else exec nice -5 $* 2>&1 fi All that nohup does is to ignore SIGHUP and SIGTERM and redirect the output if it is not already redirected. Before job control this was all that was needed to avoid a controlling terminal disconnection from killing the process. Unfortunately with job control a little more is needed. Bob ___ 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
Bob Proulx wrote: NOT this: $* >>nohup.out.$name-$pid But this: $* | sed "s/^/$name-$pid: /" >> nohup.out $* | sed "s/^/$timestamp: /" >> nohup.out OH! I see now... yea, that would require active participation. trap "" 1 15 if test -t 2>&1 ; then echo "Sending output to 'nohup.out'" exec nice -5 $* >>nohup.out 2>&1 else exec nice -5 $* 2>&1 fi All that nohup does is to ignore SIGHUP and SIGTERM and redirect the output if it is not already redirected. Before job control this was all that was needed to avoid a controlling terminal disconnection from killing the process. Unfortunately with job control a little more is needed. Trapping the signals in the shell does not trap them in the exec'd child program, so I don't see how this would work. ___ 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: >> trap "" 1 15 >> if test -t 2>&1 ; then >> echo "Sending output to 'nohup.out'" >> exec nice -5 $* >>nohup.out 2>&1 >> else >> exec nice -5 $* 2>&1 >> fi >> >> All that nohup does is to ignore SIGHUP and SIGTERM and redirect the >> output if it is not already redirected. Before job control this was >> all that was needed to avoid a controlling terminal disconnection from >> killing the process. Unfortunately with job control a little more is >> needed. > > Trapping the signals in the shell does not trap them in the exec'd child > program, so I don't see how this would work. Untrue, actually: _handling_ the signals would not handle them in the exec'd child (for obvious reasons), but POSIX requires blocked signals to remain blocked after an exec. Try the following: #!/bin/sh trap "" TSTP exec yes > /dev/null and then try suspending the program with ^Z, with and without the "trap" line commented out. :) -- 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
Micah Cowan wrote: Untrue, actually: _handling_ the signals would not handle them in the exec'd child (for obvious reasons), but POSIX requires blocked signals to remain blocked after an exec. Try the following: #!/bin/sh trap "" TSTP exec yes > /dev/null and then try suspending the program with ^Z, with and without the "trap" line commented out. :) Interesting... I thought that exec reset all signal handlers to their default behavior... ___ 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
Micah Cowan <[EMAIL PROTECTED]> writes: > Untrue, actually: _handling_ the signals would not handle them in the > exec'd child (for obvious reasons), but POSIX requires blocked signals > to remain blocked after an exec. trap "" is not about blocking a signal, but ignoring it. 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: nohup feature request / Please fwd to Jim Meyering
Andreas Schwab wrote: > Micah Cowan <[EMAIL PROTECTED]> writes: > >> Untrue, actually: _handling_ the signals would not handle them in the >> exec'd child (for obvious reasons), but POSIX requires blocked signals >> to remain blocked after an exec. > > trap "" is not about blocking a signal, but ignoring it. Yeah, my terminology's apparently not so great today: "exec'd child" is another goof (s/b "exec'd process"). -- 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
