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



bug#30534: cp - Possible bugs when not preserving mode (explicit) and when copying special files

2018-02-20 Thread Declercq Laurent

Le 20/02/2018 à 04:26, Pádraig Brady a écrit :

2. Non-permission bits are preserved, even when the --no-preserve=mode
option is involved.

Original file to copy: prwSrw-rw- 1 root staff 0 févr. 18 18:59 spfile
cp(1) command (run as root user): cp -r --no-preserve=mode spfile
spfile_copy

Current result:

prwsr-xr-x 1 root staff 0 févr. 18 22:05 spfile_copy

I'm not seeing this. I get 'x' rather than 's' here (and '-' with the fix)


Expected result (considering UMASK 0022 and without the first bug above):

prw-r--r-- 1 root staff 0 févr. 18 22:05 spfile_copy

thanks!
Pádraig



I'll make a new try, providing you relevant STRACE(1) output if necessary.

Thank you for your fast reaction.

<>