On Thu, Jun 13, 2019 at 05:27:37PM -0700, Michael Forney wrote: > Thanks for looking this over. > > On 2019-06-13, Richard Ipsum <[email protected]> wrote: > > I might be wrong but I think this will cause a subtle change in > > behaviour since the umask is needed to correctly interpret the mode > > string. One example that's documented in chmod(1p) is "-w" vs "a-w". > > "a-w" removes all write perms, but "-w" removes only the permissions > > that weren't filtered by the mask. This could explain why this > > is currently being done in two separate steps. > > umask(0) sets the mask to 0 and returns the old mask, so I think the > mode is interpreted the same way before and after this change > (getumask() is even implemented as two calls to umask, returning the > result of the first call).
Ah right, I read this thinking the mask passed to the mode string parser would be 0, but obviously it's not. So you pass the existing mode while setting the mask to 0 so that you can use the final mode as the argument to mkfifo, and get rid of the chmod call, nice. Thanks, Richard
