Re: coding standards

[don fong]

Clark,

Just took a look at the code and it is an int:


declaring boolean quantities as int is a common practice in old C code.
indeed, all the boolean vars in this program seem to be declared as int.
at least, i don't see anything declared as bool.

declared type notwithstanding, in the context of subst.c, check_nullness
is being used as a boolean.  unfortunately, in retrospect the snippets i
posted are not as clear as i had thought.  (is there a way to provide a URL
for subst.c that links back to the devel branch at git.savannah.gnu.org?
as can be done with github or gitlab.)

consider:

* there is only one line where check_nullness is set to a non-zero value.
* that line is executed at most once.
* it does check_nullness++ which is another common practice for setting
  a boolean variable in C code.

 8449   check_nullness++;

* there are at least 2 other references to check_nullness in a boolean
context:

 8689   if (check_nullness)

 8687   var_is_null = check_nullness && (var_is_set == 0 || *temp == 0);

while these boolean-style references may not prove that check_nullness
is boolean, it at least shows that using it as a boolean is not inconsistent
with existing practices.

if you agree it's a boolean, wouldn't it be better to test its truth/falsity
directly instead of comparing it to false (0)?  the latter seems like a
typical "trap" that coding pundits warn against.

consistency would also argue for using the same variable name,
check_nullness
(as in my patch) instead of check_null (as in the altered version).










On Sun, Mar 4, 2018 at 6:15 PM, Clark Wang  wrote:

> On Mon, Mar 5, 2018 at 9:13 AM, don fong  wrote:
>
>> Clark, thanks for your answer.
>>
>> I use ``if (flag)'' only when `flag' is a boolean.
>>
>>
>> but in this case, it *is* a boolean, as i stated, and as can be seen in
>> subst.c:
>>
>> +{
>> +  if (check_nullness)
>> +  report_error (_("%s: parameter null or not set"), name);
>> +  else
>> +  report_error (_("%s: parameter is not set"), name);
>> +}
>>
>
> Just took a look at the code and it is an int:
>
> @@ -6849,8 +6849,9 @@ parameter_brace_expand_rhs (name, value, c, quoted,
> pflags, qdollaratp, hasdolla
> used as the error message to print, otherwise a standard message is
> printed. */
>  static void
> -parameter_brace_expand_error (name, value)
> +parameter_brace_expand_error (name, value, check_nullness)
>   char *name, *value;
> + int check_nullness;
>  {
>WORD_LIST *l;
>char *temp;
>
>

Re: add generated files to .gitignore

[Mike Frysinger]

On 05 Mar 2018 14:33, Chet Ramey wrote:
> On 3/5/18 1:15 PM, Mike Frysinger wrote:
> > On 02 Mar 2018 14:25, Chet Ramey wrote:
> >> On 2/27/18 11:46 AM, don fong wrote:
> >>> Chet, thanks for the suggestion.
> >>>
> >>> i still wonder what's the objection to changing .gitignore?
> >>
> >> I don't think it will be useful to me, since I curate the commits I
> >> make to the various branches, but I don't have any real objection if
> >> it will help others.
> > 
> > i wish the bash/readline git repos had .gitignore in them so every
> > dev didn't have to create it by hand themselves
> 
> OK, since the bash devel branch has one, I assume you mean the master
> branches for bash/readline?

all the active branches that people would normally use :)

so yeah, master & devel would be great, and as new branches are cut
off of master/devel, they'll get them for free.  i don't think there's
any need to backport to older stuff.
-mike


signature.asc
Description: Digital signature

Re: add generated files to .gitignore

[Chet Ramey]

On 3/5/18 1:15 PM, Mike Frysinger wrote:
> On 02 Mar 2018 14:25, Chet Ramey wrote:
>> On 2/27/18 11:46 AM, don fong wrote:
>>> Chet, thanks for the suggestion.
>>>
>>> i still wonder what's the objection to changing .gitignore?
>>
>> I don't think it will be useful to me, since I curate the commits I
>> make to the various branches, but I don't have any real objection if
>> it will help others.
> 
> i wish the bash/readline git repos had .gitignore in them so every
> dev didn't have to create it by hand themselves

OK, since the bash devel branch has one, I assume you mean the master
branches for bash/readline?

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

Re: add generated files to .gitignore

[Mike Frysinger]

On 02 Mar 2018 14:25, Chet Ramey wrote:
> On 2/27/18 11:46 AM, don fong wrote:
> > Chet, thanks for the suggestion.
> > 
> > i still wonder what's the objection to changing .gitignore?
> 
> I don't think it will be useful to me, since I curate the commits I
> make to the various branches, but I don't have any real objection if
> it will help others.

i wish the bash/readline git repos had .gitignore in them so every
dev didn't have to create it by hand themselves
-mike


signature.asc
Description: Digital signature

Re: [off-topic] ksh local vars [was: Unset array doesn't work]

[Koichi Murase]

2018-03-05 22:57 GMT+09:00 Greg Wooledge :
> On Sat, Mar 03, 2018 at 08:24:06PM +0900, Koichi Murase wrote:
>> - Note: ksh seems not support local variables. "typeset" in function
>> scopes defines a global variable, and "unset" removes the global
>> variable.
>
> "Real ksh" has two different kinds of functions -- ones declared with
> "foo()" and ones declared with "function foo".  They have different
> treatment of local variables, and the ksh man page does not clearly
> (at least to me) describe the difference.
>

Thank you for the information. I actually tested with the following
version of ksh:

$ ksh --version
version sh (AT Research) 93u+ 2012-08-01

I tried again for ksh with the two kinds of functions. I considered
the following script:

echo local typeset
echo A: $(f() { typeset a=2; echo f:a=$a; }; f; echo g:a=$a)
echo B: $(function f { typeset a=2; echo f:a=$a; }; f; echo g:a=$a)

echo local-scope unset
echo A: $(a=1; f() { typeset a=2; echo f:a=$a; unset a; echo
f:a=$a; }; f; echo g:a=$a)
echo B: $(a=1; function f { typeset a=2; echo f:a=$a; unset a;
echo f:a=$a; }; f; echo g:a=$a)

echo previous-scope unset
echo A: $(a=1; u() { echo u:a=$a; unset a; }; f() { typeset a=2;
echo f:a=$a; u; echo f:a=$a; }; f; echo g:a=$a)
echo B: $(a=1; function u { echo u:a=$a; unset a; }; function f {
typeset a=2; echo f:a=$a; u; echo f:a=$a; }; f; echo g:a=$a)

echo local typeset without value
echo A: $(a=set; f() { typeset a; echo ${a-unset}; }; echo $a; f; echo $a)
echo B: $(a=set; function f { typeset a; echo ${a-unset}; }; echo
$a; f; echo $a)

The result was:

local typeset
A: f:a=2 g:a=2
B: f:a=2 g:a=
local-scope unset
A: f:a=2 f:a= g:a=
B: f:a=2 f:a= g:a=1
previous-scope unset
A: f:a=2 u:a=2 f:a= g:a=
B: f:a=2 u:a=1 f:a=2 g:a=
local typeset without value
A: set set set
B: set unset set

This means that `typeset' defines a global variable in the `foo()'
form of ksh functions, and defines a local variable in the `function
foo' form. Also I noticed that in the `function foo' form of
functions, if the variable is not defined in the local scope, the
variable name always refers to the global one even if the caller
function defines a local variable with the same name. The `unset'
builtin removes local variables in the `function foo' form of
functions if it is defined, and otherwise it removes global variables.
In the `function foo' form, when a local variable is defined without a
value, the variable has the `unset' state.

2018-03-05 23:49 GMT+09:00 Martijn Dekker :
> In the current "real ksh", AT ksh93, things changed in radical and
> incompatible ways. Functions defined with "foo()" don't have local
> variables at all. Functions defined with "function foo" have a new model
> for local variables: static scoping. That is, if x calls y, then y does
> *not* have access to x's local variables. In static scoping, "unset" in
> a local scope can never influence the global scope. No other shell to
> date has emulated the ksh93 model.

Thank you very much for the additional information. The ksh that I
tested was actually ksh93, and your explanation helped me to
understand the behavior.

--
Koichi

Re: unexpected behavior with read

[Greg Wooledge]

On Sun, Mar 04, 2018 at 06:15:05PM -0500, Zach Hadgraft wrote:
> Description:
> global variable assignments fail when part of a sequence that
> includes read and begins with a function invoked by command substitution
> read can be invoked by another function, or invoked by another
> command and the result is the same

As Chet said, command substitution runs in a subshell, which means
side effects (global variable changes, changing directory, etc.) are
discarded.

If your actual goal is to send information from a function back to the
caller, please see .

[off-topic] ksh local vars [was: Unset array doesn't work]

[Martijn Dekker]

Op 05-03-18 om 13:57 schreef Greg Wooledge:
> On Sat, Mar 03, 2018 at 08:24:06PM +0900, Koichi Murase wrote:
>> - Note: ksh seems not support local variables. "typeset" in function
>> scopes defines a global variable, and "unset" removes the global
>> variable.
> 
> "Real ksh" has two different kinds of functions -- ones declared with
> "foo()" and ones declared with "function foo".  They have different
> treatment of local variables, and the ksh man page does not clearly
> (at least to me) describe the difference.

You have to distinguish between two kinds of ksh here.

In the old "real ksh", AT ksh88 (which is closed source and only in
current use as /usr/xpg4/bin/sh on Solaris), functions defined with
"foo()" and with "function foo" have identical behaviour with regards to
local variables. They have dynamic scoping, that is, if x calls y, then
y has access to x's local variables. This is the model that every other
current shell, including bash, emulates -- each with its own particular
set of quirks and gotchas, of course. That includes the "ksh clones"
(pdksh, mksh, et al) which are all ksh88 clones.

In the current "real ksh", AT ksh93, things changed in radical and
incompatible ways. Functions defined with "foo()" don't have local
variables at all. Functions defined with "function foo" have a new model
for local variables: static scoping. That is, if x calls y, then y does
*not* have access to x's local variables. In static scoping, "unset" in
a local scope can never influence the global scope. No other shell to
date has emulated the ksh93 model.

HTH,

- M.

Re: Unset array doesn't work

[Greg Wooledge]

On Sat, Mar 03, 2018 at 08:24:06PM +0900, Koichi Murase wrote:
> - Note: ksh seems not support local variables. "typeset" in function
> scopes defines a global variable, and "unset" removes the global
> variable.

"Real ksh" has two different kinds of functions -- ones declared with
"foo()" and ones declared with "function foo".  They have different
treatment of local variables, and the ksh man page does not clearly
(at least to me) describe the difference.

So, although this is slightly off-topic for bug-bash, here's a brief
demonstration:

wooledg:~$ ksh
$ rand() { nameref r="$1"; r=$RANDOM; }
$ rand foo
$ echo "$foo"
16875
$ rand r
ksh: typeset: r: invalid self reference

That much is just like bash.  Bash can do "local -n" to mimic "nameref"
but there is a variable name collision issue that makes it difficult
(or impossible) to use safely.

$ function rand2 { nameref r="$1"; r=$RANDOM; }
$ rand2 foo
$ echo "$foo"
4768
$ rand2 r
$ echo "$r"
28060

But with this kind of function, nameref actually *works* the way one
expects.  The collision issue is gone.  The function is able to receive
variable names as arguments and reference them in the caller's scope to
retrieve or store (send back) values, safely, no matter what variable
name the caller uses.

Bash does not have anything like this, and the attempts to create
something like this were what led to Freddy Vulto's "upvar" trick,
and much of the ensuing discussion.

I have not investigated how unset works in ksh's two different kinds
of functions, but if you only checked one of them, you may wish to
check the other as well.