Re: [SUGGESTION] nohup_${PID}.out
Dear Boruch, Let me start out by saying that your request of doing something new in a compiled tool, which can be done with scripting in the shell as it works now, albeit with a slight bit more typing, goes directly against the UNIX mentality of "do one thing, and do it well" modular design paradigm. Each coreutil is "one thing, done well" even if they don't have that motto officially. Perhaps they do; it would be interesting to know! Because of execve, you already know the PID and it won't change. You can then use that to output to ${pid} anywhere in your output filename. Adding features, which duplicate what can be done already in a script, also has the potential to add all of: complexity, bugs, support requirements, and feature creep. nohup would now do more things, perhaps not as well as someone other than yourself may want them to be done. Perhaps I don't want my file to be called nohup.${pid}.out. Perhaps I want my file to be ${pid}.nohup. Maybe I want my file to be called ${executable}.${pid} I can do any of these today, with a bit of extra thought and typing. Should nohup instead support token parsing, in addition to the seemingly simple request of a ${pid} in the output filename, just to allow me to add a filename pattern for it to create? If the feature was hardcoded, then I would potentially become angry that such a bothersome new almost-feature was added that did not meet my requirements, yet almost worked. I cannot tell you just how many times "almost features" have plagued me in my 20 years of systems administration. Usually I work around said "almost features" with more script logic, and become happier with the resultant output. I don't ask that multiple developers work harder on maintaining a project just to satisfy potential requirements. I _like_ scripting a bit more, to output precisely what I want to see. So please consider this when asking for an extra feature, which is fully implementable as it exists today in a script, versus adding more code to the 'one thing well' coreutil 'nohup'. It really isn't a great value vs time, support, debugging, and user-complaining proposition for doing it the way one person in the future dislikes. (For examples of this, find on this list the _multi-year_ angry-user feedback of changing the default quoting style of "ls" .. ) This feature request will almost certainly not see implementation. Its nothing personal; its entirely a logistical pain. Kind regards, Mike On Tue, Feb 20, 2018 at 4:11 AM, Boruch Baumwrote: > On 2018-02-19 09:17, Kamil Dudka wrote: > > As far as I can tell, all your suggestions can be implemented as a shell > > script that uses the current implementation of nohup. Have you tried it? > > Yes. I didn't post the suggestion in order to have the coreutils team > solve a personal problem of mine. The purpose was to propose features > that I think would be widely used and appreciated. > > -- > hkp://keys.gnupg.net > CA45 09B5 5351 7C11 A9D1 7286 0036 9E45 1595 8BC0 > >
Re: [SUGGESTION] nohup_${PID}.out
On 2018-02-19 09:17, Kamil Dudka wrote: > As far as I can tell, all your suggestions can be implemented as a shell > script that uses the current implementation of nohup. Have you tried it? Yes. I didn't post the suggestion in order to have the coreutils team solve a personal problem of mine. The purpose was to propose features that I think would be widely used and appreciated. -- hkp://keys.gnupg.net CA45 09B5 5351 7C11 A9D1 7286 0036 9E45 1595 8BC0
Re: [SUGGESTION] nohup_${PID}.out
On Monday, February 19, 2018 12:30:33 AM CET Boruch Baum wrote: > On 2018-02-19 00:14, Bernhard Voelker wrote: > > Have a nice day, > > Berny > > Thank you for the kind wishes. I hope the list will continue to consider > the entirety of the suggestions in my post. As far as I can tell, all your suggestions can be implemented as a shell script that uses the current implementation of nohup. Have you tried it? Kamil
Re: [SUGGESTION] nohup_${PID}.out
On 02/19/2018 12:30 AM, Boruch Baum wrote: I hope the list will continue to consider the entirety of the suggestions in my post. What exactly do you refer to? I think the other suggestions seem to be based on knowing the PID, so given that this doesn't change due to execve(), a workaround seems to be possible already, e.g. a custom output logfile name "nohup.PID.out": exec nohup some/prg > nohup.$$.out Regarding an option writing the PID: well, what about all the other utilities executing other processes like env, nice, time, ionice, xargs, ...? It sounds like to become quite some bloat to the code of all the utilities of this class - especially as the PID does not change due to execve(). Have a nice day, Berny
Re: [SUGGESTION] nohup_${PID}.out
On 2018-02-19 00:14, Bernhard Voelker wrote: > Have a nice day, > Berny Thank you for the kind wishes. I hope the list will continue to consider the entirety of the suggestions in my post. -- hkp://keys.gnupg.net CA45 09B5 5351 7C11 A9D1 7286 0036 9E45 1595 8BC0
Re: [SUGGESTION] nohup_${PID}.out
On 02/18/2018 12:26 PM, Boruch Baum wrote: 1] Wouldn't it be useful for nohup to indicate the PID of the process it spawns? nohup(1) does *not* create a new process. Instead, it invokes execve to replace its own image with that of the new one (in the same process), i.e., there is no new PID. You can check via strace(1) to see what happens. P.S. Often one sends such a process to the background - as you said with '&': $ nohup sleep 1000 & This is a shell feature, and you can use $! to get the PID for further tracking etc., e.g.: $ kill $! Have a nice day, Berny
[SUGGESTION] nohup_${PID}.out
ref: nohup (GNU coreutils) 8.23 1] Wouldn't it be useful for nohup to indicate the PID of the process it spawns? 1.1] What comes to mind would be to have nohup send the PID to either STDOUT or STDERR, and also to send it as a first line to its output file. 1.1.1] It would also be helpful for nohup to send to its output file the text of the command line that it spawned. 1.2] This would be useful to help: 1.2.1] track the process 1.2.2] send it signals 1.2.3] identify what exactly this output file is recording 1.3] This behavior would be consistent with what bash does when ending a comamnd with '&'; it indicates the PID and job number. 2.] Also, I would find it useful for nohup to have options to produce a {quasi-,}unique output file: 2.1] nohup_${PID}.out 2.2] nohup_${PID}_${RANDOM}.out For your consideration, -- hkp://keys.gnupg.net CA45 09B5 5351 7C11 A9D1 7286 0036 9E45 1595 8BC0