Re: RFC: Enabling or disabling tracing shell functions
On Sun, Jun 5, 2016 at 8:48 PM, Chet Ramey wrote:
> "Traced functions inherit the DEBUG and RETURN traps from the calling
> shell."
Why did RETURN originally get sucked into set -T? Was it supposed to
be primarily for debugging? Some functions actually use it for
internal purposes and enabling -T to debug causes (probably unwanted)
side-effects in such cases since there's no way to control their
inheritance separately.
If the goal is to inspect values when a function returns that can be
accomplished with just a DEBUG trap:
trap 'if [[ $LASTFUNC != ${FUNCNAME[0]} ]]; then ...;
LASTFUNC=${FUNCNAME[0]}; fi' DEBUG
Re: PS1 \# doesn't take into account HISTIGNORE and HISTCONTROL
On 6/2/16 2:43 PM, Carlos Morata wrote: > Hi, > > I think you misunderstod me. > I'm really interested in working with relative command history expasions. > So I need to work with !-$((\#-cmdnumbertarget)), not with !$HISTCMD. > > I figure it out pretty well already but I think this is a bug cause you > loose all the relative history expansions when you hit HISTCONTROL or > HISTIGNORE and that doesn't get well with the principle of least surprise. I'm not sure I understand. If you turn on options and variables that affect which commands are saved in the command history and how they are saved (or affect the history list when they are saved, like erasedups), it seems reasonable to expect that to affect the history number. If you want the history list to reflect exactly the commands you enter, unset HISTCONTROL and HISTIGNORE. That way you can use something like "!-3" with more confidence. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: bash: Please make bash build reproducibly
(Chet, your specific attention is required for this email, please) Ximin Luo: > On Sat, 28 May 2016 13:38:35 +0200 Reiner Herrmann wrote: >> After that, the only remaining issue is that the included header file >> /usr/include/bash/config.h varies depending on the kernel version used >> during build [1] (with kernel <4, PGRP_PIPE is defined). > > For this particular example, we can just patch this out, i.e. remove it from > the installed config.h. Debian already forces PGRP_PIPE 1 in config-bot.h, > which config.h includes at the end. > I dug into this a bit more and it looks like the cause of the difference is this snippet from configure.ac: linux*) LOCAL_LDFLAGS=-rdynamic # allow dynamic loading case "`uname -r`" in 2.[[456789]]*|3*) AC_DEFINE(PGRP_PIPE) ;; esac ;; This was added between bash-3.0.16 and bash-3.1, way before Linux 4 came out. So I wonder if this snippet should instead be: linux*) LOCAL_LDFLAGS=-rdynamic # allow dynamic loading case "`uname -r`" in 1.*|2.[[0123]]*) true ;; *) AC_DEFINE(PGRP_PIPE) ;; esac ;; to set this for all future kernels? Then Debian (and probably other distros) could get rid of our patch, too. However, the question still remains why config.h is installed into the end-user system, and if bash-built-with-linux-5 required PGRP_PIPE to be *undefined*, we would still have a reproducibility problem. Ximin -- GPG: ed25519/56034877E1F87C35 GPG: rsa4096/1318EFAC5FBBDBCE git://github.com/infinity0/pubkeys.git
Re: 4.3.42 : shopt -s lastpipe & "no record of process" warnings
On 6/5/16 9:10 AM, Jason Vas Dias wrote: > With a build of bash 4.3 patchlevel 42 > on a Linux x86_64 system I am getting > warning messages on stderr when > running a certain script like: >"wait_for: no record of process 8278" . > Running bash with the script as > input under strace shows that process 8277 > does a successful wait4(-1,...) which DOES > return pid 8278 . So why is bash complaining > it has no record of it ? Try running this with the devel version or any of the bash-4.4 prerelease versions. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: RFC: Enabling or disabling tracing shell functions
On 6/2/16 9:20 AM, Paulo César Pereira de Andrade wrote: > Hi, > > This is a "RFC" to update documentation to better match behavior, > or, to get some information about shell tracing. > > Bellow I am quoting a request from an user: > > ---8<--- > The bash shell offers the xtrace (set -x), functrace (set -T) and > function trace (typeset -ft) facilities to control script and function > tracing yet it appears that only set -x is effective, tracing the > calling script + any and all called functions. The problem is faulty assumptions, leading to an incorrect conclusion. Execution tracing uses `set -x, global shell function tracing is `set -T', and `typeset -ft' turns on function tracing for an individual function. The mistake is assuming that function tracing and execution tracing are the same thing. They're not. Function tracing exists primarily for use by the shell's debugging mode, which implements execution tracing and breakpoints using the DEBUG trap; the manual says: "Traced functions inherit the DEBUG and RETURN traps from the calling shell." and "-T If set, any traps on DEBUG and RETURN are inherited by shell functions, command substitutions, and commands executed in a subshell environment. The DEBUG and RETURN traps are normally not inherited in such cases." The rest of the proposal assumes some other meaning for `function tracing' than what exists in bash. This special meaning for -t when used with -f and shell function names could possibly appear in some future version of bash, using another option letter, but it won't happen until at least bash-5.0, if ever. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: declare ref[x] segfault and garbage values
On 6/2/16 7:08 AM, Grisha Levit wrote: > These are maybe similar to the less-interesting issue of namerefs pointing > to array subscripts, but are triggered by relatively normal assignments: All the same problem, with the same fix: accurately reproducing the original name and assignment statement with the value of the nameref substituted for the original name. The code was not as careful about transferring values to use the new name as it should be. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: mapfile creates poorly-named array if passed nameref to array subscript
On 6/1/16 10:45 PM, Grisha Levit wrote: > I guess it’s even more general than just list assignments. See also below > problems with |declare|: These are all the same problem, and the same as the previous report. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: 4.3.42 : shopt -s lastpipe & "no record of process" warnings
OK, I found one fix - you probably
won't like it, but it fixes the oroblem,
and all the test cases run in
'make test' still work - especially
'run_jobs' and 'run_lastpipe' -
the patch simply removes the error
from the FIND_CHILD macro in jobs.c,
so it noe reads ;
jobs.c @ line 2377:
#define FIND_CHILD(pid,child) \
do \
{\
child = find_pipeline (pid, 0, (int*)NULL); \
if ( child == 0 ) \
{ \
give_terminal_to (shell_pgrp, 0); \
UNLOCK_CHILD (oset); \
restore_sigint_handler (); \
return (termination_state = 0): \
} \
} \
while (0)
So I've removed the manufactured
"No record of process X" error altogether,
and yet all test cases still pass - it seems
it was unecessary.
Will a fix for this issue appear in a 'bash43-43+' patch
file or in the forthcoming bash-4.4 release ?
I think it should, as it is rather unfair of bash to make its
internal bookkeeping errors appear as if they could be
user programming errors.
Regards,
Jason
On 05/06/2016, Jason Vas Dias wrote:
> The strace log shows that process 8277 is the
> bash subshell that runs f() , forks to create 8278,
> which forks to execve "some_executable" ;
> process 8277 then eads the 8278 output on a pipe,
> so it knows when the pipe is closed, amd the strace
> log shows 8277 first does a wait4, which returns 8278,
> but does NOT get a SIGCHLD event for 8278.
> Maybe this is the problem? Since the wait has
> already succeeded, no SIGCHLD will be generated.
> 8277 evidently is not aware that its 8278 child has exited,
> and goes on to issue a further wait4 for it which
> returns -1 with errno==ECHLD and then emits the
> message:
> "xxx.sh: line 46: No record of process 8278" .
> Line 46 in my script consist of
> function f()
> .
> This seems buggy to me - I'll try developing a
> patch to fix it and will post back here.
>
> Regards, Jason
> On 05/06/2016, Jason Vas Dias wrote:
>> With a build of bash 4.3 patchlevel 42
>> on a Linux x86_64 system I am getting
>> warning messages on stderr when
>> running a certain script like:
>>"wait_for: no record of process 8278" .
>> Running bash with the script as
>> input under strace shows that process 8277
>> does a successful wait4(-1,...) which DOES
>> return pid 8278 . So why is bash complaining
>> it has no record of it ?
>> Is bash getting its book-keeping wrong here?
>> The script is not using any background
>> jobs with '&' or using the 'wait' built-in.
>> It is simply doing something like:
>>
>> shopt -s lastpipe;
>> set -o pipefail;
>> function f()
>> { some_executable "$@" | {
>> while read line; do { ... ; } done;
>>}
>>return 0;
>> }
>> ...
>> f $args | { while read result; do
>> ...; done ; }
>>
>>
>> So I'd expect the initial bash process to run
>> a subshell bash to invoke the f() function,
>> which runs a command child that execve-s
>> "some_executable', parsing its output and writing
>> to the subshell bash on a pipe, which writes to the
>> parent bash on a pipe, which parses it & does whatever.
>> Without the lastpipe option, this would be the
>> other way round - the parent would run f, and
>> its output would be parsed in the subshell
>> running the f output parsing loop.
>> All this seems to work OK, but why the warning
>> message about "no record of process X"?
>> Or is this message indicating something has
>> gone seriously wrong ?
>> Thanks in advance for any replies,
>> Regards,
>> Jason
>>
>
Re: 4.3.42 : shopt -s lastpipe & "no record of process" warnings
The strace log shows that process 8277 is the
bash subshell that runs f() , forks to create 8278,
which forks to execve "some_executable" ;
process 8277 then eads the 8278 output on a pipe,
so it knows when the pipe is closed, amd the strace
log shows 8277 first does a wait4, which returns 8278,
but does NOT get a SIGCHLD event for 8278.
Maybe this is the problem? Since the wait has
already succeeded, no SIGCHLD will be generated.
8277 evidently is not aware that its 8278 child has exited,
and goes on to issue a further wait4 for it which
returns -1 with errno==ECHLD and then emits the
message:
"xxx.sh: line 46: No record of process 8278" .
Line 46 in my script consist of
function f()
.
This seems buggy to me - I'll try developing a
patch to fix it and will post back here.
Regards, Jason
On 05/06/2016, Jason Vas Dias wrote:
> With a build of bash 4.3 patchlevel 42
> on a Linux x86_64 system I am getting
> warning messages on stderr when
> running a certain script like:
>"wait_for: no record of process 8278" .
> Running bash with the script as
> input under strace shows that process 8277
> does a successful wait4(-1,...) which DOES
> return pid 8278 . So why is bash complaining
> it has no record of it ?
> Is bash getting its book-keeping wrong here?
> The script is not using any background
> jobs with '&' or using the 'wait' built-in.
> It is simply doing something like:
>
> shopt -s lastpipe;
> set -o pipefail;
> function f()
> { some_executable "$@" | {
> while read line; do { ... ; } done;
>}
>return 0;
> }
> ...
> f $args | { while read result; do
> ...; done ; }
>
>
> So I'd expect the initial bash process to run
> a subshell bash to invoke the f() function,
> which runs a command child that execve-s
> "some_executable', parsing its output and writing
> to the subshell bash on a pipe, which writes to the
> parent bash on a pipe, which parses it & does whatever.
> Without the lastpipe option, this would be the
> other way round - the parent would run f, and
> its output would be parsed in the subshell
> running the f output parsing loop.
> All this seems to work OK, but why the warning
> message about "no record of process X"?
> Or is this message indicating something has
> gone seriously wrong ?
> Thanks in advance for any replies,
> Regards,
> Jason
>
4.3.42 : shopt -s lastpipe & "no record of process" warnings
With a build of bash 4.3 patchlevel 42
on a Linux x86_64 system I am getting
warning messages on stderr when
running a certain script like:
"wait_for: no record of process 8278" .
Running bash with the script as
input under strace shows that process 8277
does a successful wait4(-1,...) which DOES
return pid 8278 . So why is bash complaining
it has no record of it ?
Is bash getting its book-keeping wrong here?
The script is not using any background
jobs with '&' or using the 'wait' built-in.
It is simply doing something like:
shopt -s lastpipe;
set -o pipefail;
function f()
{ some_executable "$@" | {
while read line; do { ... ; } done;
}
return 0;
}
...
f $args | { while read result; do
...; done ; }
So I'd expect the initial bash process to run
a subshell bash to invoke the f() function,
which runs a command child that execve-s
"some_executable', parsing its output and writing
to the subshell bash on a pipe, which writes to the
parent bash on a pipe, which parses it & does whatever.
Without the lastpipe option, this would be the
other way round - the parent would run f, and
its output would be parsed in the subshell
running the f output parsing loop.
All this seems to work OK, but why the warning
message about "no record of process X"?
Or is this message indicating something has
gone seriously wrong ?
Thanks in advance for any replies,
Regards,
Jason
