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

Re: remove empty '' in ${var@Q} result?

2017-11-08 Thread Chet Ramey
On 11/7/17 11:38 PM, Clark Wang wrote: > I made a patch (also attached). Please see if it's ok. > > > Updated by dealing with empty strings (and malloc'ing 2 more bytes) > though I'm not sure if it's necessary since the func > sh_quote_reusable() already handles empty

Re: umask builtin

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

Re: Claim `declare' as a special command in manual?

2017-11-08 Thread Eduardo A . Bustamante López
On Wed, Nov 08, 2017 at 12:20:23PM +0800, Clark Wang wrote: [...] > It seems to me bash internally parses the `declare' command specially and > (logically) convert `declare -a arr=()' to two statements `declare -a arr' > and `arr=()'. There is indeed special treatment for assignment builtins in

Re: Claim `declare' as a special command in manual?

2017-11-08 Thread Chet Ramey
On 11/7/17 11:20 PM, Clark Wang wrote: > For now the `declare' command is under SHELL BUILTIN COMMANDS in the man > page so people may think bash parses the command line parameters the same > way as other built-in commands which is not true. Only assignment statements, as described in the manual

Re: Claim `declare' as a special command in manual?

2017-11-08 Thread Chet Ramey
On 11/8/17 8:48 AM, Eduardo A. Bustamante López wrote: > As a side note, this special treatment does lead to some weirdness around > shadowing assignment builtins with functions, or using them with the `builtin' > builtin: Yes, the `builtin' builtin removes the special treatment. Only the

Re: umask builtin

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

Re: umask builtin

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

Re: umask builtin

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

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 > wrote: > > in my version 4.4.0(1), > `umask' gives me a numeric output of `0022', > while `umask -S' gives me an output of