On Fri, Jan 7, 2011 at 11:06 PM, Jim Meyering <[email protected]> wrote: > 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.
Yes, right. Then, touch only supposed to change file's timestamp. No? But, touch also creates a file for us. Not only it creates a file for us, when it creates a file it takes reference from other files. So, althrough we're in philosophy of one-tool-do-one-job-well, there are something else that we can get. And if adding --mode option to touch gets really out of philosophy, then I think we need a new tool to for creating file with all the options that we might have want. That will truly help us to keep the philosophy intact. > > Why would one prefer the GNU-specific touch --mode ... > over the portable combination of touch and chmod? > Cause its easier to do 'touch --mode xxx filename' than 'touch filename' and 'chmod xxx'. And Eric also pointed out that we will be able to do 'touch -r a -M b' to create a referenced file with different mode. thanks, rakib
