Re: umask builtin

[kalle]

> I linked the POSIX standard document in my reply. Here it is
> again: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/umask.html
> 
> That is how the standard specifies the behavior of the umask builtin.
> If your question
> is "why is it shown in that way", then the answer is: "because that's
> what the standard
> says". If you're not happy with the standard, you can go and ask the
> Austin Group
> about it.
> 

I see. This is the wrong place for this debate.

Re: umask builtin

[kalle]

Am 08.11.2017 um 16:36 schrieb Eduardo Bustamante:
> On Wed, Nov 8, 2017 at 10:06 AM, kalle  wrote:
> [...]
>>> From umask(1p):
>>>   For a symbolic_mode value, the new value of the file mode creation mask
>>>   shall be the logical complement of the file permission bits portion  of
>>>   the file mode specified by the symbolic_mode string.
>>
>> This sentence is inacceptably complicate. Furthermore, it is not clear
>> which symbolic mode string is meant at the end of the sentence, but I
>> suppose it has been written by you to undermine the given facts.
> 
> Eh, what?

sorry, this was really a wrong formulation - I meant "it has been cited
by you as an argument for the status quo"

Re: umask builtin

[Eduardo Bustamante]

On Wed, Nov 8, 2017 at 10:06 AM, kalle  wrote:
[...]
>> From umask(1p):
>>   For a symbolic_mode value, the new value of the file mode creation mask
>>   shall be the logical complement of the file permission bits portion  of
>>   the file mode specified by the symbolic_mode string.
>
> This sentence is inacceptably complicate. Furthermore, it is not clear
> which symbolic mode string is meant at the end of the sentence, but I
> suppose it has been written by you to undermine the given facts.

Eh, what?

> Am 08.11.2017 um 15:01 schrieb Eduardo A. Bustamante López:
>> Hm, is there a umask program that does this?
>>
>> Looking at the shells I have installed, they all do pretty much the same:
[...]
>
> I did not question this...
>
> it's just not the easiest logic to have different logics.
> or is the different behavior made clear in some other documentation than
> 'man 1p umask'?

I linked the POSIX standard document in my reply. Here it is
again: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/umask.html

That is how the standard specifies the behavior of the umask builtin.
If your question
is "why is it shown in that way", then the answer is: "because that's
what the standard
says". If you're not happy with the standard, you can go and ask the
Austin Group
about it.

Re: umask builtin

[Greg Wooledge]

On Wed, Nov 08, 2017 at 05:06:36PM +0100, kalle wrote:
> Am 08.11.2017 um 14:55 schrieb DJ Mills:
> > From umask(1p):
> >   For a symbolic_mode value, the new value of the file mode creation mask
> >   shall be the logical complement of the file permission bits portion  of
> >   the file mode specified by the symbolic_mode string.
> 
> This sentence is inacceptably complicate. Furthermore, it is not clear
> which symbolic mode string is meant at the end of the sentence, but I
> suppose it has been written by you to undermine the given facts.

The (1p) means that this is directly from POSIX.  It is a POSIX man
page.

If you're on a Debian system, you can read it by doing this:

apt-get install manpages-posix
man 1p umask

Ask your OS support how to do the equivalent on other OSes, or try
searching for them via Google.  I'm sure they can be found online
somewhere.

Re: umask builtin

[kalle]

Am 08.11.2017 um 14:55 schrieb DJ Mills:
> 
> 
> On Wed, Nov 8, 2017 at 6:04 AM, kalle  > wrote:
> 
> in my version 4.4.0(1),
> `umask' gives me a numeric output of `0022',
> while `umask -S' gives me an output of `u=rwx,g=rx,o=rx'.
> Shouldn't umask -S also formulate the mask in a negative way, as does
> `umask'? Thus giving out `u=,g=w,o=w'?
> 
> greetings,
> kalle
> 
> 
> From umask(1p):
>   For a symbolic_mode value, the new value of the file mode creation mask
>   shall be the logical complement of the file permission bits portion  of
>   the file mode specified by the symbolic_mode string.

This sentence is inacceptably complicate. Furthermore, it is not clear
which symbolic mode string is meant at the end of the sentence, but I
suppose it has been written by you to undermine the given facts.

But this existing practice of having different logics whether the mode
is presented in numeric or symbolic way  is the questionable thing..

Am 08.11.2017 um 15:01 schrieb Eduardo A. Bustamante López:
> Hm, is there a umask program that does this?
>
> Looking at the shells I have installed, they all do pretty much the same:
>
> dualbus@ubuntu:~$ for sh in bash dash ksh93 mksh posh zsh; do echo $sh
$($sh -c 'echo $(umask) $(umask -S)'); done
> bash 0022 u=rwx,g=rx,o=rx
> dash 0022 u=rwx,g=rx,o=rx
> ksh93 0022 u=rwx,g=rx,o=rx
> mksh 022 u=rwx,g=rx,o=rx
> posh 022 u=rwx,g=rx,o=rx
> zsh 022 u=rwx,g=rx,o=rx
>

I did not question this...

it's just not the easiest logic to have different logics.
or is the different behavior made clear in some other documentation than
'man 1p umask'?

kalle

Re: umask builtin

[Eduardo A . Bustamante López]

On Wed, Nov 08, 2017 at 12:04:08PM +0100, kalle wrote:
> in my version 4.4.0(1),
> `umask' gives me a numeric output of `0022',
> while `umask -S' gives me an output of `u=rwx,g=rx,o=rx'.
> Shouldn't umask -S also formulate the mask in a negative way, as does
> `umask'? Thus giving out `u=,g=w,o=w'?

Hm, is there a umask program that does this?

Looking at the shells I have installed, they all do pretty much the same:

dualbus@ubuntu:~$ for sh in bash dash ksh93 mksh posh zsh; do echo $sh $($sh -c 
'echo $(umask) $(umask -S)'); done
bash 0022 u=rwx,g=rx,o=rx
dash 0022 u=rwx,g=rx,o=rx
ksh93 0022 u=rwx,g=rx,o=rx
mksh 022 u=rwx,g=rx,o=rx
posh 022 u=rwx,g=rx,o=rx
zsh 022 u=rwx,g=rx,o=rx

Which is also what POSIX specifies: 
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/umask.html

| If -S is specified, the message shall be in the following format:
| 
| "u=%s,g=%s,o=%s\n", , ,
| 
| 
| where the three values shall be combinations of letters from the set 
| { r, w, x}; the presence of a letter shall indicate that the corresponding
| bit is clear in the file mode creation mask.

Re: umask builtin

[DJ Mills]

On Wed, Nov 8, 2017 at 6:04 AM, kalle  wrote:

> in my version 4.4.0(1),
> `umask' gives me a numeric output of `0022',
> while `umask -S' gives me an output of `u=rwx,g=rx,o=rx'.
> Shouldn't umask -S also formulate the mask in a negative way, as does
> `umask'? Thus giving out `u=,g=w,o=w'?
>
> greetings,
> kalle
>
>
>From umask(1p):
  For a symbolic_mode value, the new value of the file mode creation mask
  shall be the logical complement of the file permission bits portion  of
  the file mode specified by the symbolic_mode string.