Re: unreliable value of LINENO variable
Confirmed on Ubuntu 22.04.3 LTS -- $ cat ~/yo.sh echo $BASH_VERSION echo 0 $LINENO if ((1)); then ( : ) | : ; echo 1 $LINENO fi echo 2 $LINENO $ for s in bash ./bash ksh zsh > do printf "\n$s\n" ; $s ~/yo.sh > done bash 5.1.16(1)-release 0 2 1 4 2 5 ./bash 5.2.21(5)-release 0 2 1 4 2 5 ksh 0 2 1 4 2 6 zsh 0 2 1 4 2 6
Re: bash encountered a coredump issue with stepping on memory
On 12/4/23 9:38 AM, wang yuhang via Bug reports for the GNU Bourne Again SHell wrote: A bash coredump has appeared in my environment, the stack information displayed by GDB is as follows: [...] the problematic bash version is 5.1.8 Hi. This appears to happen when creating a shell variable from the initial environment. I can't reproduce it. If you can find a way to reliably reproduce it, please let me know and we can work on it. -- ``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/ OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Idea: jobs(1) -i to print only :%ID:s
Chet Ramey wrote in
<7402031f-424c-4766-ba70-71771c9dc...@case.edu>:
|On 11/8/23 8:12 PM, Steffen Nurpmeso wrote:
|> The "problem" with the current way bash is doing it is that bash's
|> job handling does not recognize jobs die under the hood:
|>
|>$ jobs
|>[1]- Stopped LESS= less -RIFe README
|>[2]+ Stopped LESS= less -RIFe TODO
|>$ kill $(jobs -p)
|>$
|>
|> ^ nothing
|>
|>$ jobs
|>[1]- Stopped LESS= less -RIFe README
|>[2]+ Stopped LESS= less -RIFe TODO
|
|Yes, the jobs are still stopped, and will remain stopped until they get
|a SIGCONT. Do you think that kill, when given a pid argument, should look
|up any job associated with that pid and send it a SIGCONT? Or should it
|send a SIGCONT to the pid unconditionally? If so, what about other
|processes in that job?
Today GMANE (through which i read bug-bash@) posted this entire
thread again! And because i am a bit afraid of Danish dynamite
(especially relaxed, or on-holiday such sort), i thought i better
do something. So what i did was as below (any usage of job_by_pid
without args 2+3==0?), and i even compiled and tested it (a bit).
Maybe you like it!
Ciao already here!
diff --git a/builtins/kill.def b/builtins/kill.def
index c655092e7b..e3caabbf73 100644
--- a/builtins/kill.def
+++ b/builtins/kill.def
@@ -85,6 +85,11 @@ int
kill_builtin (list)
WORD_LIST *list;
{
+#if defined (JOB_CONTROL)
+ sigset_t set, oset;
+ JOB *j;
+ int job;
+#endif
int sig, any_succeeded, listing, saw_signal, dflags;
char *sigspec, *word;
pid_t pid;
@@ -194,6 +199,14 @@ use_sigspec:
{
pid = (pid_t) pid_value;
+#if defined (JOB_CONTROL)
+ BLOCK_CHILD (set, oset);
+ job = get_job_by_pid ((pid_t) pid_value, 0, 0);
+ if (job != NO_JOB)
+ goto jisjob;
+ UNBLOCK_CHILD (oset);
+#endif
+
if (kill_pid (pid, sig, pid < -1) < 0)
{
if (errno == EINVAL)
@@ -214,10 +227,6 @@ use_sigspec:
else if (*word)
/* Posix.2 says you can kill without job control active (4.32.4) */
{ /* Must be a job spec. Check it out. */
- int job;
- sigset_t set, oset;
- JOB *j;
-
BLOCK_CHILD (set, oset);
job = get_job_spec (list);
@@ -229,6 +238,7 @@ use_sigspec:
CONTINUE_OR_FAIL;
}
+jisjob:
j = get_job_by_jid (job);
/* Job spec used. Kill the process group. If the job was started
without job control, then its pgrp == shell_pgrp, so we have
--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
|
| Only in December: lightful Dubai COP28 Narendra Modi quote:
| A small part of humanity has ruthlessly exploited nature.
| But the entire humanity is bearing the cost of it,
| especially the inhabitants of the Global South.
| The selfishness of a few will lead the world into darkness,
| not just for themselves but for the entire world.
Re: unreliable value of LINENO variable
On Mon, Dec 04, 2023 at 12:21:11PM -0500, Chet Ramey wrote: > On 12/4/23 8:46 AM, Giacomo Comes wrote: > > I use often the value of LINEO in order > > to know where to look for issues in a script. > > Recently I discovered a bug. > > > > Please consider the following 6 line script: > > > > #!/bin/bash > > > > if ((1)); then > > ( : ) ; echo 1 $LINENO > > fi > > echo 2 $LINENO > > > > if executed it should print: > > 1 4 > > 2 6 > > And indeed that's the output if I run it on openSUSE Leap 15.5 > > (bash 4.4). However if I execute it on openSUSE tumbleweed > > (bash 5.2) the output is: > > 1 4 > > 2 5 > > I can't reproduce this. I get the correct (bash-4.4) results on bash-5.1 > and bash-5.2. There does seem to be a problem with bash-5.0, but it was > corrected in bash-5.1, according to my results. > > This is the case for both of your example scripts. > The script I was using was more complicated. I did simplify it and I tested the simpler version only with bash 5.0, assuming it would fail with 5.1 and 5.2 too. The following one fails with every 5.x version: #!/bin/bash if ((1)); then ( : ) | : ; echo 1 $LINENO fi echo 2 $LINENO Need to add a pipe after the subshell command.
Re: unreliable value of LINENO variable
i ve experienced many ghost fails .. got better over time and knowerledge greets On Mon, Dec 4, 2023, 18:21 Chet Ramey wrote: > On 12/4/23 8:46 AM, Giacomo Comes wrote: > > I use often the value of LINEO in order > > to know where to look for issues in a script. > > Recently I discovered a bug. > > > > Please consider the following 6 line script: > > > > #!/bin/bash > > > > if ((1)); then > > ( : ) ; echo 1 $LINENO > > fi > > echo 2 $LINENO > > > > if executed it should print: > > 1 4 > > 2 6 > > And indeed that's the output if I run it on openSUSE Leap 15.5 > > (bash 4.4). However if I execute it on openSUSE tumbleweed > > (bash 5.2) the output is: > > 1 4 > > 2 5 > > I can't reproduce this. I get the correct (bash-4.4) results on bash-5.1 > and bash-5.2. There does seem to be a problem with bash-5.0, but it was > corrected in bash-5.1, according to my results. > > This is the case for both of your example scripts. > > -- > ``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: unreliable value of LINENO variable
On 12/4/23 8:46 AM, Giacomo Comes wrote: I use often the value of LINEO in order to know where to look for issues in a script. Recently I discovered a bug. Please consider the following 6 line script: #!/bin/bash if ((1)); then ( : ) ; echo 1 $LINENO fi echo 2 $LINENO if executed it should print: 1 4 2 6 And indeed that's the output if I run it on openSUSE Leap 15.5 (bash 4.4). However if I execute it on openSUSE tumbleweed (bash 5.2) the output is: 1 4 2 5 I can't reproduce this. I get the correct (bash-4.4) results on bash-5.1 and bash-5.2. There does seem to be a problem with bash-5.0, but it was corrected in bash-5.1, according to my results. This is the case for both of your example scripts. -- ``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/ OpenPGP_signature.asc Description: OpenPGP digital signature
bash encountered a coredump issue with stepping on memory
Hi A bash coredump has appeared in my environment, the stack information displayed by GDB is as follows: #0 __pthread_kill_implementation (threadid=
unreliable value of LINENO variable
I use often the value of LINEO in order to know where to look for issues in a script. Recently I discovered a bug. Please consider the following 6 line script: #!/bin/bash if ((1)); then ( : ) ; echo 1 $LINENO fi echo 2 $LINENO if executed it should print: 1 4 2 6 And indeed that's the output if I run it on openSUSE Leap 15.5 (bash 4.4). However if I execute it on openSUSE tumbleweed (bash 5.2) the output is: 1 4 2 5 I compiled and tested several version of bash and the conclusion is that the bug is not there up to bash 4.4.18 and it shows up in bash-5.0-alpha and later releases. In order to trigger the bug in your script you need: 1) a compound command executed in a subshell ( : ) 2) included in if then fi The LINENO variable will start to show an incorrect value immediatly after the fi reserved word. Example: #!/bin/bash if ((1)); then ( : ) ; echo 1 $LINENO : # echo 3 $LINENO fi echo 2 $LINENO correct output with 4.4: 1 4 3 7 2 9 wrong output with 5.x: 1 4 3 7 2 5 Please let me know if you need more infotrmation.
