Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: msys
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash.exe' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='msys' -DCONF_MACHTYPE='x86_64-pc-msys' -DCONF_VENDOR='pc'
-DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -
> 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: "becaus
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 perm
Am 08.11.2017 um 14:55 schrieb DJ Mills:
>
>
> On Wed, Nov 8, 2017 at 6:04 AM, kalle <mailto:ka...@projektwerkstatt.de>> wrote:
>
> in my version 4.4.0(1),
> `umask' gives me a numeric output of `0022',
> while `umask -S' gives me an
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