coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Rakib Mullick
Subject: Re: [coreutils] RFC for adding file creation mode feature into touch utility.
Date: Sat, 8 Jan 2011 22:30:40 +0600

On Sat, Jan 8, 2011 at 3:02 PM, Jim Meyering <address@hidden> wrote:
> Rakib Mullick wrote:
>>> 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.
>
> ?
>
> When the utility of a new feature is not obvious, the proposal for
> that new feature must be accompanied by significant justification,
> and so far, the argument that "adding this option to touch saves us the
> trouble of invoking chmod" is insufficient.
>
> Typical "good" justification usually goes like this:
>
>    I want to do X using POSIX tools, and the portable way to do it is
>    too cumbersome, but if I add this option to one of the coreutils,
>    it becomes much easier.  Here is how to do X using current tools:
>
>        ...list of actual commands (inefficient, cumbersome, etc)...
>
>    and now, do X using the program with the proposed change:
>
>        ...list of commands demonstrating benefits of proposed change...
>
> Then, if there is no reasonably simple/concise way to solve the problem
> with some other tool, we evaluate whether some coreutils program
> should be extended to do the job.
>
>>> 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'.
>
> As mentioned above, that is not enough justification.
>
>> 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.
>
> Let's back up a step...
> Why do you want an option for this when you can already use touch
> to create a file with selected permissions via your umask?

I think umask change the the file creation mask system wide. I might
not want it for every file I create.

> If you say that you require an execute bit or some special bit to
> be set, please explain why.  I do not see how having such bits set
> on an empty file would be useful.  If you're about to add content,

No. It's not just about setting an execute bit, say I might have
create a file with 'sudo touch filename', in that case I just can see
the file by doing 'cat filename' or 'vim filename'. So, again I need
to do, 'sudo chmod xxx filename' to make it available to its user. So,
it can be summed up as:

(Assume, to create a file under /usr/src/work)
             sudo touch /usr/src/work/filename (to create a file)
             sudo chmod xxx /usr/src/work/filename (to give a user
proper permission)

After adding this feature we can do this:
            sudo touch --mode xxx /usr/src/work/filename

thats it.

> then the time stamps set by touch will be overwritten, and you might as
> well have created the file via the shell, (if there was only one) say
> with ": > FILE".
>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]