Jeff wrote,
| Hello, I just tried setting umask as follows
|
| --------------------------
| UMASK=744
Uh oh. You should have set it to 033 or 022.
| :0w:
| * stuff here
| REPORT=| ( munpack -C blahblah ; mv --backup=numbered blahblah yaddayadda )
|
| :0e:
| LOG="$REPORT$NL"
| UMASK=600
You should have set it to 066 or 177. You also should have braces around the
LOG= assignment.
| According to the man page, it is supposed to interpret the number as octal.
| I'm assuming that it's *exactly* the way chmod would. Apparently not.
Not as chmod does, but as sh's umask does: it's the set of bits you want OFF,
not those you want ON (such as you would tell chmod). It's still octal if
that's any comfort.
| Files created from the munpack/mv have a protection mask of -----w--w- ...
That's not the mask; that's the permission. The mask is the set of bits to
turn off. The x bits would be off anyway, and a 744 umask explains why user
has no perms at all and why nobody can read.
| and files created after that point have a protection mask of ----rw-rwx.
I don't know why other-execute bit is on, but a 600 umask explains why the
protection forbids the user to read or write.
| Can someone tell me what is going on?
Yes; setting UMASK, like setting umask, says which bits to turn off, but you
expected it to say which bits to turn on. Think of a mask as, well, a mask:
if a place exists on the mask, then the corresponding point on the face is NOT
seen. You see the parts of the face where the mask has a hole or where it
doesn't reach.
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail