Re: [SUGGESTION] nohup_${PID}.out

2018-02-20 Thread Mike Hodson
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 Baum  wrote:

> 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

2018-02-20 Thread Boruch Baum
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

2018-02-19 Thread Kamil Dudka
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

2018-02-19 Thread Bernhard Voelker

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

2018-02-18 Thread Boruch Baum
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

2018-02-18 Thread Bernhard Voelker

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