Hi Saher,
SAHER MOHAMED <[email protected]> writes:
> I would like to propose a new --mode=MODE option for touch.
>
> The option specifies the permissions used when touch creates a file that
> does not already exist.
>
> For example:
>
> touch --mode=0755 script.sh
> touch --mode=0600 private-file
>
> The behavior is:
>
> - MODE is interpreted as an octal file mode.
> - The mode applies only when a new file is created.
> - Existing files retain their current permissions.
> - The resulting permissions remain subject to the process umask.
> - Normal touch behavior is unchanged when --mode is not specified.
>
> The motivation is to allow callers to control permissions at file creation
> time instead of requiring a separate chmod operation afterward.
Thanks for the detailed explanation.
This feature has been requested previously, but was rejected [1].
Interestingly, in the discussion thread I don't see a mention of
'install' [2]. Using 'touch' then 'chmod' works, but my preference is
using an invocation of 'install' like this:
$ install -m 600 /dev/null secret
$ stat -c %A secret
-rw-------
It feels a tiny bit safer to me that way. I guess you could also use a
subshell with a restrictive umask to acomplish this as well:
$ (rm secret; umask 177 && touch secret)
$ stat -c %A secret
-rw-------
But 'install' seems most intuitive there, at least to me. Perhaps there
is a documentation improvement there, since it is slightly different
than the typical use case of installing just compiled software.
> I have included implementation changes, documentation, and tests in the
> attached patch.
>
> The patch is also available in my public Coreutils fork on the
> touch-mode-option branch.
>
> Feedback on the interface and behavior would be appreciated.
I don't see the patch attachment. Did you forget it, or maybe your email
didn't get along with the mail server?
Collin
[1] https://www.gnu.org/software/coreutils/rejected_requests.html#touch
[2] https://lists.gnu.org/archive/html/coreutils/2011-01/msg00025.html
