Re: problem with bash script loading

[Paulo Nogueira]

On Sat, 29 Dec 2018, Chet Ramey wrote:



http://lists.gnu.org/archive/html/bug-bash/2018-09/msg00023.html




 Not sure if I understood everything, so allow me to quote you,
 from
 http://lists.gnu.org/archive/html/bug-bash/2018-09/msg00024.html


... It's been there
even since I wrote the buffered input code in 1992, and it's more about
making sure parent and child shells have a consistent view of the script
in case the child expects to read from it. It's about being careful, not
explicitly allowing self-modifying scripts.



 What occurred to me is the following: suppose a script s1 starts
 being executed, by forking say, and then s1 is overwritten; bash
 detects this and re-reads the file. OK, then exactly where does
 bash continue executing the script s1 if changes were made
 throughout the file, even before the current location pointer?
 (in relative terms, of course)

 Does it count the number of bytes? The number of records?
 I cannot see any consistent way. It seems impossible, in
 general, to avoid at least one of the following cases:

 (1) executing commands that are present in at least one of
the files, but which (in a given situation) wouldn't be
executed if either file were to be run as a whole

 (2) executing commands that are *not* present in either file
(ie, the older and newer versions of s1), for example
"garbage" commands that make the execution abort

 Both cases may lead, for instance, to the deletion of files
 that had never been intended to be deleted, and so on...

 And that, if true, would make your consistency argument kind
 of secondary, so to say (in my opinion, of course).

 Best regards,
  Paulo Nogueira

Identical function names in bash source code

[Peng Yu]

Hi,

It is not uncommon to see the same name is used to defined functions
in different .c files in bash source code.

For example, sh_single_quote is defined in both lib/readline/shell.c
and lib/sh/shquote.c with the exact same signature. The two pieces of
code are slightly different. Do they do the exact same things or do
something different?

In either case, is having the same name for different functions a good
practice? This will make the linked binary dependent on the order of
the corresponding .a files specified. Or if linked via .o files, then
one function will shadow the others. See 1) and 2) below for minimal
working examples. Neither cases seem to be good and could be avoided
easily by giving the functions unique names.

So, should such functions with the same name be named differently? Thanks.

// lib/readline/shell.c
/* Does shell-like quoting using single quotes. */
char *
sh_single_quote (char *string)
{
  register int c;
  char *result, *r, *s;

  result = (char *)xmalloc (3 + (4 * strlen (string)));
  r = result;
  *r++ = '\'';

  for (s = string; s && (c = *s); s++)
{
  *r++ = c;

  if (c == '\'')
  {
*r++ = '\\';  /* insert escaped single quote */
*r++ = '\'';
*r++ = '\'';  /* start new quoted string */
  }
}

  *r++ = '\'';
  *r = '\0';

  return (result);
}

// lib/sh/shquote.c
/* Return a new string which is the single-quoted version of STRING.
   Used by alias and trap, among others. */
char *
sh_single_quote (string)
 const char *string;
{
  register int c;
  char *result, *r;
  const char *s;

  result = (char *)xmalloc (3 + (4 * strlen (string)));
  r = result;

  if (string[0] == '\'' && string[1] == 0)
{
  *r++ = '\\';
  *r++ = '\'';
  *r++ = 0;
  return result;
}

  *r++ = '\'';

  for (s = string; s && (c = *s); s++)
{
  *r++ = c;

  if (c == '\'')
  {
*r++ = '\\';  /* insert escaped single quote */
*r++ = '\'';
*r++ = '\'';  /* start new quoted string */
  }
}

  *r++ = '\'';
  *r = '\0';

  return (result);
}

# 1 ##
==> libprint1.c <==
// vim: set noexpandtab tabstop=2:
#include 

void print() {
  puts("Hello World1!\n");
}

==> libprint2.c <==
// vim: set noexpandtab tabstop=2:
#include 

void print() {
  puts("Hello World2!\n");
}

==> main.c <==
// vim: set noexpandtab tabstop=2:

void print();
int main() {
  print();
  return 0;
}

==> main.sh <==
#!/usr/bin/env bash
# vim: set noexpandtab tabstop=2:

set -v
gcc -g -Wall -pedantic -c -o libprint1.o libprint1.c
gcc -g -Wall -pedantic -c -o libprint2.o libprint2.c
ar cr libprint1.a libprint1.o
ar cr libprint2.a libprint2.o
gcc -g -Wall -pedantic -c -o main.o main.c
gcc -o main.exe main.o libprint1.a libprint2.a
./main.exe
gcc -o main.exe main.o libprint2.a libprint1.a
./main.exe
$ ./main.sh
gcc -g -Wall -pedantic -c -o libprint1.o libprint1.c
gcc -g -Wall -pedantic -c -o libprint2.o libprint2.c
ar cr libprint1.a libprint1.o
ar cr libprint2.a libprint2.o
gcc -g -Wall -pedantic -c -o main.o main.c
gcc -o main.exe main.o libprint1.a libprint2.a
./main.exe
Hello World1!

gcc -o main.exe main.o libprint2.a libprint1.a
./main.exe
Hello World2!

# 2 ##
==> libprint1.c <==
// vim: set noexpandtab tabstop=2:
#include 

void print() {
  puts("Hello World1!\n");
}

==> libprint2.c <==
// vim: set noexpandtab tabstop=2:
#include 

void print() {
  puts("Hello World2!\n");
}

==> main.c <==
// vim: set noexpandtab tabstop=2:

void print();
int main() {
  print();
  return 0;
}

==> main.sh <==
#!/usr/bin/env bash
# vim: set noexpandtab tabstop=2:

set -v
gcc -g -Wall -pedantic -c -o libprint1.o libprint1.c
gcc -g -Wall -pedantic -c -o libprint2.o libprint2.c
ar cr libprint.a libprint1.o libprint2.o
gcc -g -Wall -pedantic -c -o main.o main.c
gcc -o main.exe main.o libprint.a
./main.exe
ar cr libprint.a libprint2.o libprint1.o
gcc -o main.exe main.o libprint.a
./main.exe

$ ./main.sh
gcc -g -Wall -pedantic -c -o libprint1.o libprint1.c
gcc -g -Wall -pedantic -c -o libprint2.o libprint2.c
ar cr libprint.a libprint1.o libprint2.o
gcc -g -Wall -pedantic -c -o main.o main.c
gcc -o main.exe main.o libprint.a
./main.exe
Hello World1!

ar cr libprint.a libprint2.o libprint1.o
gcc -o main.exe main.o libprint.a
./main.exe
Hello World1!

-- 
Regards,
Peng

Re: Identical function names in bash source code

[Eduardo A . Bustamante López]

On Sat, Jan 05, 2019 at 08:19:38AM -0600, Peng Yu wrote:
> Hi,
> 
> It is not uncommon to see the same name is used to defined functions
> in different .c files in bash source code.
> 
> For example, sh_single_quote is defined in both lib/readline/shell.c
> and lib/sh/shquote.c with the exact same signature. The two pieces of
> code are slightly different. Do they do the exact same things or do
> something different?
> 
> In either case, is having the same name for different functions a good
> practice? This will make the linked binary dependent on the order of
> the corresponding .a files specified. Or if linked via .o files, then
> one function will shadow the others. See 1) and 2) below for minimal
> working examples. Neither cases seem to be good and could be avoided
> easily by giving the functions unique names.
> 
> So, should such functions with the same name be named differently? Thanks.

This mailing list (bug-bash) is for reporting BUGS. If you must, at least please
use help-bash for generic questions?

Although you should probably be asking this to a C programming forum...

Re: Identical function names in bash source code

[don fong]

for my 2c, the post seems within the charter.

quoting from the bug-bash info
page:

> This list distributes, to the active maintainers of BASH (the Bourne Again
> SHell), bug reports and fixes for, and *suggestions for improvements in
> BASH. *




On Sat, Jan 5, 2019 at 9:15 AM Eduardo A. Bustamante López <
dual...@gmail.com> wrote:

> On Sat, Jan 05, 2019 at 08:19:38AM -0600, Peng Yu wrote:
> > Hi,
> >
> > It is not uncommon to see the same name is used to defined functions
> > in different .c files in bash source code.
> >
> > For example, sh_single_quote is defined in both lib/readline/shell.c
> > and lib/sh/shquote.c with the exact same signature. The two pieces of
> > code are slightly different. Do they do the exact same things or do
> > something different?
> >
> > In either case, is having the same name for different functions a good
> > practice? This will make the linked binary dependent on the order of
> > the corresponding .a files specified. Or if linked via .o files, then
> > one function will shadow the others. See 1) and 2) below for minimal
> > working examples. Neither cases seem to be good and could be avoided
> > easily by giving the functions unique names.
> >
> > So, should such functions with the same name be named differently?
> Thanks.
>
> This mailing list (bug-bash) is for reporting BUGS. If you must, at least
> please
> use help-bash for generic questions?
>
> Although you should probably be asking this to a C programming forum...
>
>

Re: Identical function names in bash source code

[Eduardo Bustamante]

On Sat, Jan 5, 2019 at 10:25 AM don fong  wrote:
>
> for my 2c, the post seems within the charter.
>
> quoting from the bug-bash info
> page:
>
> > This list distributes, to the active maintainers of BASH (the Bourne Again
> > SHell), bug reports and fixes for, and *suggestions for improvements in
> > BASH. *

What would you say the "suggested improvement" is here?

To me, it reads as a generic C programming question that just happens
to use the source tree of GNU bash / GNU readline as an example.

Re: Identical function names in bash source code

[Peng Yu]

> What would you say the "suggested improvement" is here?

This is implied. If it is agreed that identical function names are not
good by the majority of bash developers, then what I found could be
turned into an explicit suggestion.

Since maybe there is a good reason, I don't want to pretend that I
knew why it was designed in this way.

So far I don't see a good reason. So I want to confirm it first.

Or this problem has never been noted before (I don't think it is very
likely, given bash has been been developed for a long time). Then, it
worth a discussion.

To me, help-bash is more for using bash for scripting. bug-bash is
more appropriate for bash development questions.

-- 
Regards,
Peng

Re: Identical function names in bash source code

[Eduardo Bustamante]

On Sat, Jan 5, 2019 at 11:38 AM Peng Yu  wrote:
>
> > What would you say the "suggested improvement" is here?
>
> This is implied. If it is agreed that identical function names are not
> good by the majority of bash developers, then what I found could be
> turned into an explicit suggestion.
>
> Since maybe there is a good reason, I don't want to pretend that I
> knew why it was designed in this way.
>
> So far I don't see a good reason. So I want to confirm it first.
>
> Or this problem has never been noted before (I don't think it is very
> likely, given bash has been been developed for a long time). Then, it
> worth a discussion.

What is the problem EXACTLY though? GNU Bash and GNU Readline are two
different code bases. Bash depends on Readline, and thus, includes the
code tree in a subfolder. It makes sense that there are similar
functions for similar functionality in two different code bases,
specially when the author/maintainer is the same person.

Re: $RANDOM not Cryptographically secure pseudorandom number generator

[Eduardo Bustamante]

On Sat, Jan 5, 2019 at 12:12 PM Eduardo A. Bustamante López
 wrote:
(...)
> 2. Performance impact
>
> The new RNG does more work, and thus, it is expected to have a performance
> impact when generating lots of random numbers. I tested 3 systems (2 amd64 
> and 1
> armhf) and include the results below.
>
>
> AMD Ryzen 7 2700X:
>
> | dualbus@system76-pc:~/src/gnu/bash$ (set -x; lscpu; for bash in /bin/bash 
> ./bash; do "$bash" ~/test-speed.sh; echo; done)
> | + lscpu
(...)

Oops, I forgot to attach the test-speed script, it's fairly simple:

| #!/bin/bash
|
| iterations=100
|
| TIMEFORMAT='time: %R'
|
| echo "iterations: $iterations"
| echo "BASH_VERSION: $BASH_VERSION"
|
| RANDOM=1
| time for ((i=0; i

"return" should not continue script execution, even if used inappropriately

[Robert Hailey]

To the most excellent bash maintainers:

I have found, what I consider to be a bug, in the following version of
bash:
* bash-4.4.23-1.fc28.x86_64

It is related to this error message:
* "return: can only `return' from a function or sourced script"

When used inappropriately (such as running a correctly-written script
that was merely intended to be sourced rather than executed), the
return statement does not cease execution, and "falls through" to
continue executing the script beyond the point that the author of the
script clearly indicated that it should cease into realms of arbitrary
and unexpected code paths.

Best wishes, kind regards, and heartfelt thank-you for your
dedicated service to the community.

--
Robert Hailey