Bash debugging.
I have been working on several items as I am using bash to configure
systems.
I started wanting to log the output of my scripts. Then I added a prefixed
message construct so detailed logs could be summarized without extraneous
debugging information (I have written an extract program using c in the
past that could also probably be written in bash (readlng a line at a time
from the log file}. The code is expected to be modified to establish
project oriented bash environment settings for the execution of the
configuration scripts. I have a function to print the bash reverse
function trace and the accumulated arguments table (BASH_ARGV). The
function is user callable .It can also be issued as the first statement of
a function call (a function trace option). Most importantly the reverse
trace is in theory (currently being tested as the initial processing for
trap statements.
Does this sound potentially like a section of the bash handbook?
Tease of the content is an example of the current bash reverse function
trace follows
#X# 2 132 bf_showTRACE 2 D 132
#D# $0=bash/functions/bf_showTRACE.sh
#D# $1=D
#D# $2=132
#D# BASH_SUBSHELL=0 TRAP={none}
#D# lCommand=bf_showTRACE
#D# lOperandCnt=2
#D# lOperand=D 132
#D# Function Back Trace
#D# LVL FUNCTION LINENO ARGC SOURCE
#D# - bf_showTRACE 132 2 bash/functions/bf_showTRACE.sh
#D# 0 bf_showTRACE 132 2 bash/functions/bf_showTRACE.sh
#D# 1 main 0 1 bash/functions/bf_showTRACE.sh
#D# 2
#D# ARGV
#D# NO VALUE
#D# 0 132
#D# 1 D
#D# 2 -X
#D# 3
The first (#X#) ;line represents an abbreviated function trace without
backtrace data.
#X# {FuncLvl} {LineNo} (FuncName) {No Args} {Args)
The next lines #D# $x={value} are debug lines that probably should be
eliminated.
The following #?# lines start
#D# - when the function is user invoked
#F# - when the function is called as the first executable line of a
function
#T# - when the function is called from a trap statement.
Display non-array BASH data
#?# BASH_SUBSHELL= ... TRAP=
Display function name (D/F) or trapped command (T)
#?# lCommand=...
Display Argument count and values
#?# lOperandCnt=...
#?# lOperands=...
Function Back Trace
Headings
#?# Function Back Trace
#?# LVL FUNCTION LINENO ARGC SOURCE
Invoked Function or Trapped Statement
Possibly this should only appear for a Trapped Statement
as for #D# and #F# this is redundant with the next line
#?# - bf_showTRACE 132 2 bash/functions/bf_showTRACE.sh
BackTrace of Function Calls
The current Function
#?# 0 bf_showTRACE 132 2 bash/functions/bf_showTRACE.sh
a Parent script invoked by bash (main)
#?# 1 main 0 1 bash/functions/bf_showTRACE.sh
A dummy source file
#?# 2
Argument trace
Headings
#?# ARGV
#?# NO VALUE
Values
function 0 above the ARGC value (2) says these are the arguments
(reverse order)
#?# 0 132
#?# 1 D
function 1 above the ARGC value (1) says this is the argument
#?# 2 -X
appears to be a dummy unused argument
#?# 3
Let me know what you think?
David Shuman
Re: read command sometimes misses newline on timeout
The read builtin could return an exit status of (128|SIGALRM) in two
circumstances:
1. If a signal is caught during the read syscall, then either the read
system call returns -1 with EINTR and the error is reported. (Otherwise it
must return a positive byte count, causing the built-in continues until it
gets a delimiter.)
2. If a signal is caught between read syscalls, it could (by a variety of
mechanisms) replace the exit status of the read built-in with a non zero
number. Presumably this is what you're seeing in fuzzing?
I will take a look at builtins/read.def when I get home. I suspect it's
looking at the "have I received SIGALRM" flag before looking at the "have I
read a delimiter" flag; I will report back on what I find.
On Fri, 4 Oct 2024, 22:18 Thomas Oettli via Bug reports for the GNU Bourne
Again SHell, wrote:
> Configuration Information [Automatically generated, do not change]:
> Machine: x86_64
> OS: linux-gnu
> Compiler: x86_64-pc-linux-gnu-gcc
> Compilation CFLAGS: -O2 -pipe
> uname output: Linux testserver 6.6.47-gentoo #1 SMP Tue Aug 20 09:38:16
> CEST 2024 x86_64 Intel(R) Xeon(R) Gold 6242 CPU @ 2.80GHz GenuineIntel
> GNU/Linux
> Machine Type: x86_64-pc-linux-gnu
>
> Bash Version: 5.2
> Patch Level: 26
> Release Status: release
>
> Description:
> I have tried to write a bash script that asynchronously reads from
> a pipe (line by line) with the help of "read -t".
> If the timeout occurs in just the right moment, read returns the full
> line, but the return code says timeout (rc > 128).
> Therefor it is not possible to know if a full line was returned or
> not. Please see the script in the Repeat-By section that reproduces the
> error in seconds.
>
>
> Repeat-By:
> function reader() {
> local buf line
> while :; do
> read -t .01 buf
> rc=$?
> if (( rc == 0 )); then
> line+=$buf
> elif (( rc > 128 )); then
> line+=$buf
> continue
> fi
> [[ $line != TEST ]] && echo Invalid line: $line && exit
> echo OK
> line=""
> done
> }
> reader < <(
> while :; do
> echo -n TEST
> sleep .00$(($RANDOM%10))
> echo
> done
> )
>
>
