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

[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 page:

"Assignment  statements  may  also  appear  as  arguments to the alias,
declare, typeset, export, readonly, and local builtin  commands
(declaration  commands)."

in the section describing how assignment statements are expanded.


-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/

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

[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 strings.
> 
> 
> Hi Chet, do you have a look at my patch?

I did. It's on the list of possible things for the next version. Since it's
only a cosmetic issue, it's not a high priority.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/

umask builtin

[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: Claim `declare' as a special command in manual?

[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 the parser:

dualbus@ubuntu:~/src/gnu/bash$ ack -H -C3 ASSIGNMENT_BUILTIN parse.y 
parse.y
5222-{
5223-  struct builtin *b;
5224-  b = builtin_address_internal (token, 0);
5225:  if (b && (b->flags & ASSIGNMENT_BUILTIN))
5226-   parser_state |= PST_ASSIGNOK;
5227-  else if (STREQ (token, "eval") || STREQ (token, "let"))
5228-   parser_state |= PST_ASSIGNOK;

> So does it make sense to move `declare' out of the SHELL BUILTIN COMMANDS
> and put it in a separate section? Or at least explicitly state that
> `declare' is special?

But is it only `declare' that is special?

According to:

dualbus@ubuntu:~/src/gnu/bash$ ack -H ASSIGNMENT_BUILTIN builtins.h 
builtins.h
45:#define ASSIGNMENT_BUILTIN 0x10  /* This builtin takes assignment 
statements. */

A builtin is an assignment builtin if builtin->flags has the ASSIGNMENT_BUILTIN
bit enabled.

You can see which builtins are assignment builtins by looking at
builtins/mkbuiltins.c:

dualbus@ubuntu:~/src/gnu/bash$ ack -H -C3 'char \*assignment_builtins' 
builtins/mkbuiltins.c 
builtins/mkbuiltins.c
154-};
155-
156-/* The builtin commands that take assignment statements as arguments. */
157:char *assignment_builtins[] =
158-{
159-  "alias", "declare", "export", "local", "readonly", "typeset",
160-  (char *)NULL


Now, there's a slight complication. Loadable builtins are also subject to this
special treatment. That is, you can define a new loadable builtin which is an
assignment builtin. Which means that if you only document the 6 builtins above
in the manual, the information will not be complete.

I think the proper approach would be to mention in the manual that there are
"assignment builtins", and that you can see the complete list with `enable
-'



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:

dualbus@ubuntu:~$ typeset -fp declare
-bash: typeset: declare: not found
dualbus@ubuntu:~$ declare a=()
dualbus@ubuntu:~$ typeset -p a
declare -a a=()
dualbus@ubuntu:~$ builtin declare b=()
-bash: syntax error near unexpected token `('
dualbus@ubuntu:~$ typeset -p b
-bash: typeset: b: not found
dualbus@ubuntu:~$ declare() { builtin declare "$@"; }
dualbus@ubuntu:~$ declare b=()
dualbus@ubuntu:~$ typeset -p b
declare -a b=()
dualbus@ubuntu:~$ declare() { echo nope "$@"; }
dualbus@ubuntu:~$ declare c=()
nope c
dualbus@ubuntu:~$ typeset -p c
declare -a c=()

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.

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: Claim `declare' as a special command in manual?

[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 command
builtin, when in posix mode, preserves the declaration command status for
the command following it. This is also documented.


-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/

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

[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

[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.