Re: [coreutils] RFC for adding file creation mode feature into touch utility.

[Jim Meyering]

Eric Blake wrote:
> On 01/07/2011 09:23 AM, Pádraig Brady wrote:
>>> Hmm - mkdir already supports -m/--mode, so it does sound like making
>>> touch support the same option might be a useful enhancement.  Of course,
>>> if the file exists, the --mode option would be ignored.  And POSIX
>>> requires that if the --mode option is not provided but a file is
>>> created, that the file have mode 0666 as modified by umask.  We can't
>>> use -m, though (POSIX already requires it for mtime).
>>
>> Why does mkdir have this option rather than relying on umask?
>> My guess is to close security races with sticky bits etc.
>> and that creating a file will not have the same issues?
>
> mkdir has -m because POSIX requires it; also, you are right that the
> setup of 'mkdir -p -m' creates a hierarchy where you want the
> permissions to be set correctly for the entire set for race avoidance.
> But touch does not create hierarchies.
>
>>
>> ...
>>> I'm 70:30 for adding this idea, and it's rather simple to do, as well
>>> (would still need doc, NEWS, and test additions).
>>
>> I'm a little less enthused to diverge from POSIX for this.
>
> It's not diverging from POSIX, so much as adding an extension.  It all
> boils down to whether the extension would prove useful, and whether it
> can optimize work flows faster than any existing alternative that gets
> the same end result but with more steps.  But thinking about it more,
> I'd rather use just the long-option --mode rather than burn a short
> option -M (or any other).
>
> As for creating a file with +x or with 07000 permissions already added,
> why?  Creating an empty file as already executable or setuid doesn't
> make much sense (the empty file will be a nop); why not wait until the
> file has final executable contents before adding +x or special
> permissions later?  So, that leaves only permissions matching of a
> reference file (and recent GNU cp already supports that), or restricting
> permissions less than touch's default of 0666 (but touch honors umask,
> so just modify your umask before touch), neither of which need a chmod
> after the fact, nor a --mode argument to touch.
>
> What would really clinch the deal is if any other touch implementation
> out there already has something like this.  But off the top of my head,
> I don't know of any (neither FreeBSD nor Solaris touch provides anything
> like this).  So I guess I'm now 50:50 (undecided on whether the
> extension makes sense without more evidence of its usefulness).

I confess that my first reaction was "why bother?"
Touch is nominally a very simple tool, and adding --mode support
feels like adding unwarranted bloat -- and not in line with
the one-job-one-tool philosophy.

Why would one prefer the GNU-specific touch --mode ...
over the portable combination of touch and chmod?