Remove unnecessary checks before calls of the function “free”

Hello, The function “free” is documented in the way that no action shall occur for a passed null pointer. It is therefore not needed that a function caller repeats a corresponding check. https://stackoverflow.com/questions/18775608/free-a-null-pointer-anyway-or-check-first This issue can be fixed

Checking evolution of information about required symbols

Hello, Some information was published with the subject “Bash-5.2 Release available” on 2022-09-26. https://lists.gnu.org/archive/html/bug-bash/2022-09/msg00056.html https://www.mail-archive.com/info-gnu@gnu.org/msg03096.html “… Bash can be linked against an already-installed Readline library rath

Re: Checking executability for asynchronous commands

>…, is not a winning argument. I got further development ideas according to the usage of wait function calls and better error reporting for asynchronous commands. >The OP seems to think that "people will occasionally forget to run `wait`", This happens for various reasons. > and wants to know

Re: Checking executability for asynchronous commands

>> Would you care if waiting on such identifications for background processes >> will occasionally be forgotten? >> >> How many efforts would you invest to add potentially missing wait function >> calls? > > It's axiomatic: if you want to make a decision based on the exit status of > any asynchron

Re: Checking executability for asynchronous commands

> If you have the pid of an asynchronous command -- and the easiest way to get > that pid > is by referencing $! after it was started -- you can call `wait' with that pid > to retrieve the status, even if it's already terminated. Would you care if waiting on such identifications for background pr

Re: Checking executability for asynchronous commands

> If you want the exit status of the child process, add `wait $!' Thanks for this information. Is there a need then to point the aspect out that exit values can be determined for child processes even if they terminated before a wait command would be performed? Regards, Markus

Re: Checking executability for asynchronous commands

> Are you maybe saying > > cmd & > > should be a special case? I got special imaginations according to such a command variant. Regards, Markus

Checking executability for asynchronous commands

Hello, I am looking for another bit of clarification according to an implementation detail. The manual is providing the following information. https://git.savannah.gnu.org/cgit/bash.git/tree/doc/bash.1?id=76404c85d492c001f59f2644074333ffb7608532#n627 “… If a command is terminated by the

Boot failure "cannot set terminal process group (-1): Inappropriate ioctl for device"

Configuration Information: Machine: x86_64 OS: linux-gnu Compiler: gcc -I/home/abuild/rpmbuild/BUILD/bash-4.2 -L/home/abuild/rpmbuild/BUILD/bash-4.2/../readline-6.2 Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-suse-linux-gnu' -DCON

Re: Bash-4.3-beta2: reserved identifier violation

> ftp://ftp.cwru.edu/pub/bash/bash-4.3-beta2.tar.gz Hello, I would like to point out that identifiers like "_ARRAY_H_" and "_PARSER_H_" do not fit to the expected naming convention of the C language standard. https://www.securecoding.cert.org/confluence/display/seccode/DCL37-C.+Do+not+declare+or+