busybox ash unespected beahviour

[Roberto A. Foglietta]

Hi all,

 much probably is an issue related to original busybox or the version used for tc.

 trap 'atexit $LINENO' EXIT

 This reports always 1 as $LINENO while it should report the line number at which exit took place.

 If $LINENO is printed in any script line, it is the correct number but not in trap.

 Just for discussion, because it is a serious limitation in debugging scripts especially when used in combination with set -e.

 Cheers, R.

[Rich]

Hi Roberto A. Foglietta
If I do this I get the same result as you, it prints 1:

Code: [Select]

trap 'echo $LINENO' EXIT
However, if I do this, it prints the line number the trap command is on:

Code: [Select]

trap "echo $LINENO" EXITI would expected  $LINENO  to represent the current line number of the file, just like  __LINE__  does in C.
The current line number in this case is the line  trap  is on.

[Rich]

Hi Roberto A. Foglietta
If you are conditionally calling  exit  in a script, replace those calls with  atexit $LINENO , which I presume is your error
handler. Then get rid of that  trap  statement.

[Roberto A. Foglietta]

@Rich: thank you for your answer.

You are right using double quotes it prints always the same line number, the line number in which trap is called because with the single quote the $LINENO is evaluated at execution (and trap works like a function: in fact if you use $LINEON in a function, it shows the line number in the function not in the script!!) instead with the double quote the $LINENO is evaluated when trap is defined.

Finally, I do not conditionally call exit in the script but I am using set -e to trap any unexpected error. This is very useful for script debugging and discover corner cases. I am used to use bash and I am used to use $LINENO but with busybox, it works differenty.

I checked the busybox website and I discovered that $LINENO has been added recently.

10 June 2019 -- BusyBox 1.31.0 (unstable)

and TinyCore Linux is using the pretty next release

25 October 2019 -- BusyBox 1.31.1 (stable)

So, I think that it is a issue related to busybox early $LINENO adoption.

[Rich]

Hi Roberto A. Foglietta
This appears to do what you want:

Code: [Select]

Please see the attached file.
Some of the technique were found here:
https://unix.stackexchange.com/questions/151771/getting-wrong-lineno-for-a-trapped-function

A couple of highlights from that link that may be of interest:

... I can think of one way you might get the behavior you expect, but it kinda screws up the shell's stderr ...

... It uses the shell's $PS4 debug prompt to define $LASTNO on every line executed. It's a current shell variable which you can access anywhere within the script. That means that no matter what line is currently being accessed, you can reference the most recent line of the script run in $LASTNO. Of course, as you can see, it comes with debug output. You can push that to 2>/dev/null for the majority of the script's execution ...

[Roberto A. Foglietta]

@Rich: thank you very much, it works!

[Rich]

Hi Roberto A. Foglietta
You are welcome. I just want to highlight a couple of points on line # 2 of the file I attached to make it clear as to
what is going on.

The  PS4=  part saves the line number of the last line executed.

The  exec 2>/dev/null  part redirects stderr output of the script so the screen doesn't get flooded with messages
due to  set -x. That's its only purpose. If you need stderr output, you can redirect it to a file or let it go to the screen..

The  set -x  part turns on script debugging which is required in order to set  PS4.  This also causes the script to output
every line it executes as well as the results to stderr, which is why  exec 2>/dev/null  was added.

[Roberto A. Foglietta]

@Rich: thank you for the explanation.

I found another way which it seems working even better.

Search for PS4= in the script of this git repository:

http://forum.tinycorelinux.net/index.php/topic,25164.0.html

I cannot post the code due to error 500 configuration in the forum.

Cheers, -R

[Rich]

Hi Roberto A. Foglietta

... Search for PS4= in the script of this git repository: ...

I saw 2 techniques.
1. Redirecting to a log file is not a bad choice.
2. Using  grep  to filter out the extra  DEBUG  messages is clever, but I got this error when I tried it:

Code: [Select]

./trap.sh: line 3: syntax error: unexpected redirectionIt seems this does not work under ash. Switching to bash got rid of the error.

[Roberto A. Foglietta]

@Rich: you are right, it does not work under ash but requires bash, unfortunately.

[Roberto A. Foglietta]

@Rich: I have created a m-list for the used and development of TinyCore Editor

m-list: https://groups.google.com/g/tinycore-editor

[Roberto A. Foglietta]

@Rich,  I have developed this way to trap errors in bash which it works also for functions. In attachment.

Three differences with ash:

1. $FUNCNAME is defined
2. set -E is available
3. trap ... ERR is available

[Roberto A. Foglietta]

@Rich, one step forward to porting the bash error management to ash

http://forum.tinycorelinux.net/index.php/topic,25195.0.html