Unexpected line number at BASH_LINENO[i]
BASH_VERSION: 5.1.4(1)-release (shipped with Debian 11)
Considering script like this:
1 #!/usr/bin/env bash
2
3 set -o errexit
4 set -o errtrace
5
6 bt() {
7 local line file file_v
8
9 for ((idx = 1; idx < ${#FUNCNAME[@]}; idx++)); do
10 read -r line _ file < <(caller $((idx - 1)))
11 file_v=${file//[\/\.]/_}
12
13 [[ -f $file ]] || continue
14
15 if [[ ! -v $file_v ]]; then
16 mapfile -t "${file_v}_ref" <"$file"
17 fi
18 local -n file_ref=${file_v}_ref
19
20 echo "$file -> $line: ${file_ref[line - 1]}"
21 done
22
23 }
24
25 a() {
26 false \
27 foo \
28 bar
29 }
30
31 trap 'bt' ERR
32
33 a
With a()'s `false` triggering the ERR trap I would expect output from bt()
to point at line 26, however, the BASH_LINENO holds, surprisingly to me,
line 27:
$ bash ./t
./t -> 27: foo \
./t -> 33: a
If I don't break the failing line then the BASH_LINENO is set just fine:
$ bash ./t
./t -> 26: false foo bar
./t -> 31: a
Same thing happens if the ERR is triggered outside the function. So like
this:
1 #!/usr/bin/env bash
2
3 set -o errexit
4 set -o errtrace
5
6 bt() {
7 local line sub file file_v
8
9 for ((idx = 1; idx < ${#FUNCNAME[@]}; idx++)); do
10 read -r line sub file < <(caller $((idx - 1)))
11 file_v=${file//[\/\.]/_}
12
13 [[ -f $file ]] || continue
14
15 if [[ ! -v ${file_v}_ref ]]; then
16 mapfile -t "${file_v}_ref" <"$file"
17 fi
18 local -n file_ref=${file_v}_ref
19
20 echo "$file -> $line: ${file_ref[line - 1]}"
21 done
22
23 }
24
25 trap 'bt' ERR
26
27 false \
28 foo \
29 bar
30
gives this:
$ bash ./t
./t -> 28: foo \
Not sure if this is expected so any hints would be appreciated. :)
Regards,
Michal
Re: Alias appends space character to end of non-latin string
On 7/1/22 4:07 AM, Vangelis Natsios wrote: Bash Version: 5.0 Patch Level: 17 Release Status: release Description: When creating an alias containing a path ending with a non-latin (e.g. greek) directory name, a space character is appended to the end of the path, causing the alias to fail. This does not happen when the non-latin part is in the middle and not the end of the path. This behaviour is new to bash v.5.0, worked as expected in v.4.X. Thanks for the report. As Lawrence said, it's simpler than that. If the alias ends in a multibyte character, it interferes with the sentinel the parser adds to the end of the alias expansion to prevent potential recursive expansion. This will be fixed in the next release candidate, and in the devel branch. -- ``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: Man page section for complete's -C option is inconsistent
On 7/6/22 7:37 PM, Mark Chandler wrote: As it stands the explanation of the -C option by itself is misleading. It doesn't mention the parameter passing at all. But it implies that all you need is a command that outputs possible completions. Particularly when you can see the following option -F explains how parameter passing is done, because that text is lacking for -C, it further implies that parameter passing is not done for -C. This is why I said that it's inconsistent. I'll add something to the -C description referencing either the -F option or the Programmable Completion section. Since the text is already there in the description of -F, it makes sense to use 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/
Re: $(( )): binary/unary VAR/NUM inconsistency
On 7/6/22 1:10 PM, Steffen Nurpmeso wrote: Hello. 'Struggling with a Dijkstra two stack parser i am thankful to be able to compare against bash that uses a completely different and correct parser! I stumbled upon this (bash 5.1.16); i find it "understandable" in respect to clarity, but inconsistent, and also in hindsight to the announcement of a forthcoming release i thought i report it quick: $ bash -c 'I=10; echo $((1++I)); echo $I' bash: line 1: 1++I: syntax error in expression (error token is "++I") $ bash -c 'I=10; echo $((1++1)); echo $I' 10 Thanks for the report. Most of these are due to bash trying to be helpful. The pre/postfix operators are parsed as such when they make sense depending on what precedes or follows them. For instance, if you have ++I, it's parsed as a pre-increment; if you have ++1, it's parsed as two unary plus operators and an integer constant. (Part of this was an attempt to be backwards compatible when I added the ++ and -- operators, since they weren't present until bash-2.04.) $ bash -c 'I=10;echo "<$(( +10+++I ))>"' <21> unary plus, constant, binary plus operator, pre-increment, variable $ bash -c 'I=10;echo "<$(( +10+ ++I ))>"' <21> same $ bash -c 'I=10;echo "<$(( +10+ +I ))>"' <20> unary plus, constant, binary plus operator, unary plus, variable -- ``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: $(( )): binary/unary VAR/NUM inconsistency
Hello! Chet Ramey wrote in <1d592238-69c5-88b6-6e08-5d56e3170...@case.edu>: |On 7/6/22 1:10 PM, Steffen Nurpmeso wrote: ... |> I stumbled upon this (bash 5.1.16); i find it "understandable" in |> respect to clarity, but inconsistent, and also in hindsight to the ... |Thanks for the report. Most of these are due to bash trying to be helpful. |The pre/postfix operators are parsed as such when they make sense depending |on what precedes or follows them. For instance, if you have ++I, it's |parsed as a pre-increment; if you have ++1, it's parsed as two unary plus |operators and an integer constant. | |(Part of this was an attempt to be backwards compatible when I added the |++ and -- operators, since they weren't present until bash-2.04.) | |> |>$ bash -c 'I=10;echo "<$(( +10+++I ))>"' |><21> | |unary plus, constant, binary plus operator, pre-increment, variable | |>$ bash -c 'I=10;echo "<$(( +10+ ++I ))>"' |><21> | |same | |>$ bash -c 'I=10;echo "<$(( +10+ +I ))>"' |><20> | |unary plus, constant, binary plus operator, unary plus, variable Funnily my parser has only one (what i know) problem left, the same as bash. On the other hand i found more. [ # make this work with (ba)sh \ command -v shopt && shopt -s expand_aliases;\ alias p=printf;alias e=echo;alias s=export # s I=10 J=33 ] e "<$(( 3 + ( 11 ) ))>" s I=10 J=33;p "<$(( +10 + + +I ))>";e "<$I>" s I=10 J=33;p "<$(( +10 + ++I ))>";e "<$I>" s I=10 J=33;p "<$(( +10 ++ +I ))>";e "<$I>" s I=10 J=33;p "<$(( +10 +++ I ))>";e "<$I>" s I=10 J=33;p "<$(( +10+++I ))>";e "<$I>" And diff -u10 OUT .nail/y/t.wysh-arith-good <14> <20><10> <21><11> <20><10> -<21><11> +<20><10> <21><11> I find bash less consistent, my thought was "either whitespace matters, then it matters, or not". (My first version removed _all_ whitespace before parsing started, which was a failure.) And one more thing. -<802379605485813759> +<9223372036854775807> This is from $ bash -c 'echo $((9))' 802379605485813759 $ dash -c 'echo $((9))' 9223372036854775807 $ busybox.static sh -c \ 'echo $((9))' 0 $ MXEXE -#:/ \ -Y 'echo $((9))' \ -Yx 9223372036854775807 (But $ bash -c 'echo $((0x8000))' -9223372036854775808 $ dash -c 'echo $((0x8000))' 9223372036854775807 $ busybox.static sh -c 'echo $((0x8000))' -9223372036854775808 $ MXEXE -#:/ -Y 'echo $((0x8000));x' -9223372036854775808 and $ MXEXE -#:/ -Y 'echo $((0x));x' -1 $ dash -c 'echo $((0x))' 9223372036854775807 $ bash -c 'echo $((0x))' -1 $ busybox.static sh -c 'echo $((0x))' -1 and $ busybox.static sh -c 'echo $((0x1))' 0 $ bash -c 'echo $((0x1))' -15 $ dash -c 'echo $((0x1))' 9223372036854775807 $ MXEXE -#:/ -Y 'echo $((0x1));x' 9223372036854775807 bash explicitly documents "no overflow checking", and things are very wild in general. My thoughts were 64-bit signed integer, but for known power-of-two bases, which are parsed as unsigned, then stored as signed 64-bit. --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)
