Re: "trap" output from "if" statement redirected wrongly
On 4/13/22 8:58 AM, Frank Heckenbach wrote: Bash Version: 5.1 Patch Level: 16 Release Status: release Description: This script writes "foo" to bar rather than stdout as I'd expect. That's not unreasonable, but it's not how it works. It's triggered by the "if" statement (which doesn't even cause running in a subshell, so it's not that). The entire `if' statement executes with its stdout redirected. That means the `false' that causes the shell to exit immediately has its stdout redirected, which the exit trap inherits. Most shells behave like bash does here; dash is a notable exception. -- ``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: "trap" output from "if" statement redirected wrongly
On Wed, Apr 13, 2022 at 02:58:30PM +0200, Frank Heckenbach wrote: > Configuration Information [Automatically generated, do not change]: > Machine: x86_64 > OS: linux-gnu > Compiler: gcc > Compilation CFLAGS: -g -O2 -fstack-protector-strong -Wformat > -Werror=format-security -Wall > uname output: Linux mars 5.10.0-12-amd64 #1 SMP Debian 5.10.103-1 > (2022-03-07) x86_64 GNU/Linux > Machine Type: x86_64-pc-linux-gnu > > Bash Version: 5.1 > Patch Level: 16 > Release Status: release > > Description: > > This script writes "foo" to bar rather than stdout as I'd expect. > > It's triggered by the "if" statement (which doesn't even cause > running in a subshell, so it's not that). > > #!/bin/bash > set -e > trap 'echo foo' 0 > #false > bar # "foo" written to stdout correctly > if true; then false; else false; fi > bar # "foo" written to bar The POSIX standard says to execute the EXIT trap in the same environment as the last command executed in the script (that first "false"). I believe that the current state of the standard streams is part of what is included in "the environment". The environment in which the shell executes a trap on EXIT shall be identical to the environment immediately after the last command executed before the trap on EXIT was taken. (from https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#trap) A trap on 0 is identical to a trap on EXIT. -- Andreas (Kusalananda) Kähäri SciLifeLab, NBIS, ICM Uppsala University, Sweden .
Building loadable builtin
I am developing a loadable builtin and I have a question about building it for distribution. I am currently building it in the "Bash-5.0 patch 17" git commit and it works fine when I run it in the bash executable built from that same commit (5.0.17(4)) but it fails when I run it in the bash from the Ubuntu 20.04 repository which is almost the same version 5.0.17(1). *bobg@goodplace:~/github/bashParse/examples/loadables$* ./ooTest.sh 5.0.17(1)-release bash: symbol lookup error: ./_bgclassCallSetup: undefined symbol: sh_xmalloc *bobg@goodplace:~/github/bashParse/examples/loadables$* ../../bash ./ooTest.sh 5.0.17(4)-release iamgrut _OID='myObj' _CLASS='MyObject' declare -- this="myObj" Question 1: what is the meaning of the (1) or (4) at the end of the bash version? Question 2: is this (...undefined symbol: sh_xmalloc) error indicative of a compiler/link option mismatch and what would it be? Question 3: what is the best practice for maintaining loadable builtins? Can anyone suggest an existing loadable builtin project that I could model mine after? Thanks, --BobG
Re: Building loadable builtin
On Thu, Apr 14, 2022 at 11:52 AM Robert E. Griffith wrote: > Question 3: what is the best practice for maintaining loadable builtins? > Can anyone suggest an existing loadable builtin project that I could > model mine after? I don't have too much advice on best practices, but I did write a blog post on writing builtins, along with some sample code, which you may find helpful. post: https://mbuki-mvuki.org/posts/2021-07-12-writing-a-bash-builtin-in-c-to-parse-ini-configs/ code: https://github.com/lollipopman/bash-ini-builtin-blog-post
Re: Building loadable builtin
Thanks Jesse, that's a great post. I wish I had found it when I started.
I wonder why its not higher on a google of "bash loadable builtin". It
would have saved me a lot of time figuring out how some of the internals
work like creating variables and understanding the global vs in-function
states.
Are there any resources available for understanding the bash internals
more?
Is this an appropriate place to ask questions on that or is there better
place for that?
Currently I am trying to figure out how to properly create a nameref
var. I specified the att_nameref attribute to make_local_variable but
when I examine the variable back in the script it is a simple variable
and not a nameref. I see specific functions in variables.h for creating
arrays but not one for namerefs.
in builtin..
// local -n this="$oid"
SHELL_VAR* this=make_local_variable("this",att_nameref);
this = bind_variable_value(this, pObj->vThis->name, 0);
..then in script...
declare -p this
..output..
declare -- this="myObj"
--BobG
On 4/14/22 12:59, Jesse Hathaway wrote:
On Thu, Apr 14, 2022 at 11:52 AM Robert E. Griffith wrote:
Question 3: what is the best practice for maintaining loadable builtins?
Can anyone suggest an existing loadable builtin project that I could
model mine after?
I don't have too much advice on best practices, but I did write a blog post
on writing builtins, along with some sample code, which you may find
helpful.
post:https://mbuki-mvuki.org/posts/2021-07-12-writing-a-bash-builtin-in-c-to-parse-ini-configs/
code:https://github.com/lollipopman/bash-ini-builtin-blog-post
Re: Building loadable builtin
On 4/14/22 12:52 PM, Robert E. Griffith wrote: I am developing a loadable builtin and I have a question about building it for distribution. I am currently building it in the "Bash-5.0 patch 17" git commit and it works fine when I run it in the bash executable built from that same commit (5.0.17(4)) but it fails when I run it in the bash from the Ubuntu 20.04 repository which is almost the same version 5.0.17(1). *bobg@goodplace:~/github/bashParse/examples/loadables$* ./ooTest.sh 5.0.17(1)-release bash: symbol lookup error: ./_bgclassCallSetup: undefined symbol: sh_xmalloc *bobg@goodplace:~/github/bashParse/examples/loadables$* ../../bash ./ooTest.sh 5.0.17(4)-release iamgrut _OID='myObj' _CLASS='MyObject' declare -- this="myObj" Question 1: what is the meaning of the (1) or (4) at the end of the bash version? It's a count of the number of times that version of bash has been built in that particular build directory. Question 2: is this (...undefined symbol: sh_xmalloc) error indicative of a compiler/link option mismatch and what would it be? Bash has a number of optional features that you can build in or out, specified at configuration time. One of those options is to build bash using the version of malloc shipped with the bash source (lib/malloc) instead of the system malloc in libc. Doing that enables malloc tracing using a wrapper function named sh_xmalloc. It looks like you built bash with the default options and Debian/Ubuntu built the version they distribute without the bash malloc. Question 3: what is the best practice for maintaining loadable builtins? Can anyone suggest an existing loadable builtin project that I could model mine after? There is no real best practice. You can model yours after the template in examples/loadables/template.c or examples/loadables/hello.c. -- ``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: Building loadable builtin
On 4/14/22 1:48 PM, Robert E. Griffith wrote:
Are there any resources available for understanding the bash internals more?
Only the source code.
Is this an appropriate place to ask questions on that or is there better
place for that?
You can ask on help-bash too, since this isn't really a bug per se. You'll
get help here, though.
Currently I am trying to figure out how to properly create a nameref var.
I specified the att_nameref attribute to make_local_variable but when I
examine the variable back in the script it is a simple variable and not a
nameref. I see specific functions in variables.h for creating arrays but
not one for namerefs.
in builtin..
// local -n this="$oid"
SHELL_VAR* this=make_local_variable("this",att_nameref);
That's not the right set of flags for make_local_variable. The constants in
variables.h beginning with MKLOC_ are the ones for the `flags' argument.
You set a variable's attributes separately from creating it.
What you probably want is something like
this = make_local_variable("this", 0);
if (this)
VSETATTR(this, att_nameref);
(not knowing what else you're doing).
--
``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/
