printf '\uFEFF' outputs invalid UTF-8 on Windows

2018-11-05 Thread Kalle Olavi Niemitalo
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' -

Re: umask builtin

2017-11-09 Thread 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: "becaus

Re: umask builtin

2017-11-09 Thread 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 perm

Re: umask builtin

2017-11-08 Thread kalle
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

umask builtin

2017-11-08 Thread kalle
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