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?
