>> But how is the system supposed to know a priori when it's such a case? The
>> default permissions that applications use handle the normal case, which is
>> that tools like text editors and shell redirection create text data files,
>> which don't need execute permissions
>I don't expect the system to know. I'm just curious why the execute bits
>are treated differently than the read and write bits. It seems like it'd
>be simpler to treat them the same in the system call, but turn them via the
>default umask.
Because a typical umask will usually give execute permission to anyone with
read permissions. And the end result will be that *every* file you created
would have execute permissions, even if it's not something that should be
executed.
And if you mask off the execute bit in your umask, then commands like ld
and mkdir will end up creating files/directories that are missing their
execute permissions, even though it's normal for these types of objects to
be executable.
The problem is that umask is normally something the user sets once at login
time, not something they adjust before each command to ensure that it
creates files with the expected permissions. It's considered to be a
per-user setting, so it needs to be appropriate for most situations. To
account for this, applications specify maximum permissions appropriate for
the types of files they normally create. And in order not to create lots
of data files with execute permissions, programs that normally create data
files don't include the execute bit.
Quote:>> On the occasions where you're creating scripts, how difficult is it to do a
>> chmod after?
>Not hard, but if I'm generating 10,000 scripts at a time, that's 10,000 calls
>to an external utility.
How many calls are you making to generate each of those scripts, and what's
one more call on top of that?
--
Level(3), Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
by