Re: Bug in documentation (man)
On 4/29/22 12:43 PM, Gasan wrote: Hi Gnu, I bash 5.1 man it says that pipeline may consist of single command. So "echo foo" is a pipeline. It also says that each command in pipeline runs in a subshell, therefore "echo foo" runs in a subshell. But thats not true. That's true. How about "each command in a multi-command pipeline is run in a subshell." -- ``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: Bug in documentation (man)
I like it! Op ma 2 mei 2022 15:05 schreef Chet Ramey : > On 4/29/22 12:43 PM, Gasan wrote: > > Hi Gnu, > > > > I bash 5.1 man it says that pipeline may consist of single command. So > > "echo foo" is a pipeline. It also says that each command in pipeline runs > > in a subshell, therefore "echo foo" runs in a subshell. But thats not > true. > > That's true. How about "each command in a multi-command pipeline is run in > a subshell." > > > -- > ``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: bash 5.1 heredoc pipes problematic, shopt needed
On 4/28/22 10:39 PM, Ángel wrote: On 2022-04-25 at 10:40 -0400, Chet Ramey wrote: Perhaps BASH_COMPAT=5.0 could be extended to handle this. I think a shopt makes more sense. Forcing heredocs to be files although something legit to request, is more a caller workaround to bugs in called programs. Shell options aren't intended to cater to broken programs; that's what the compatibility mode is for. It's not `legit to request'; the only thing guaranteed is that the user will get a file descriptor they can read from. This response originally surprised me, but you have a point. The interface is just a fd, and usage of a file an implementation detail. Still, based on what surfaced on this thread, one might argue the need for a *seekable* fd, in which case we end up in a pretty similar situation. https://lists.gnu.org/archive/html/bug-bash/2019-03/msg00082.html A seekable fd could be made with Linux-specific memfd_create(), maybe worth considering. You can't make that file descriptor read-only. https://lists.gnu.org/archive/html/bug-bash/2019-03/msg00083.html I see a pattern there where a heredoc is converted to a fd (pipe/file), then the fd is (often) made into a bash buffered input. I think that going directly from heredoc to the buffered input would allow avoiding the temporary file/pipe altogether, and the penalty associated with 1- byte reads in the case where it is not going to a separate program. That probably requires some refactoring to work out though. They're two separate operations, and have to be kept separate semantically to be compatible with historical usage. It boils down to the read builtin recognizing when the file descriptor it's using for input is a here- document and using a separate internal buffer, right? Is that much of a special case worth the code it would take to implement? PS: Looking at the use_tempfile branch (actually the part fulfilled by sh_mktmpfd), that could benefit from O_TMPFILE | O_EXCL on modern Linux kernels. https://lists.gnu.org/archive/html/bug-bash/2019-03/msg00091.html You can't make that file descriptor read-only either (nor is it portable). My preference is a portable memfd_create(); I think I could get around its limitations. -- ``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/
[PATCH] fix bug in print loadable builtin
ansicstr() returns NULL when the string argument is the empty string, so passing its return value to fprintf() will cause a segmentation fault. That happened when one of the arguments was the empty string and the `-r' option was not used. example: bash-5.1$ enable -f /usr/lib/bash/print print bash-5.1$ (print '') Segmentation fault (core dumped) bash-5.1$ (print -r '') bash-5.1$ (print a '' b) Segmentation fault (core dumped) --- examples/loadables/print.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/examples/loadables/print.c b/examples/loadables/print.c index 0120dbf4..6be2778a 100644 --- a/examples/loadables/print.c +++ b/examples/loadables/print.c @@ -181,8 +181,11 @@ printargs (list, ofp) for (sawc = 0, l = list; l; l = l->next) { ostr = ansicstr (l->word->word, strlen (l->word->word), 0, &sawc, (int *)0); - fprintf (ofp, "%s", ostr); - free (ostr); + if (ostr) +{ + fprintf (ofp, "%s", ostr); + free (ostr); +} if (sawc) return (0); if (l->next) -- 2.36.0
Re: [PATCH] fix bug in print loadable builtin
On 5/2/22 11:28 AM, Emanuele Torre wrote: ansicstr() returns NULL when the string argument is the empty string, so passing its return value to fprintf() will cause a segmentation fault. Thanks for the report. -- ``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: bash 5.1 heredoc pipes problematic, shopt needed
On Mon, May 2, 2022 at 9:53 AM Chet Ramey wrote: > My preference is a portable memfd_create(); I think I could get around > its limitations. I'm sure you can google with the best of them, but I did come across this project which did some work trying to create a portable version of memfd_create(), https://github.com/lassik/shm_open_anon
execute_cmd.h is not included in installed headers
"execute_cmd.h" is not listed in the INSTALLED_HEADERS macro which determines which headers are included for the install-headers target. Is it problematic for a loadable builtin to execute shell functions or is it maybe an oversight that that header is not included? If I build against the full source it appears to work fine but I wonder if there are edge cases that cause problems. If my builtin should not use functions from execute_cmd.h, is there a safe way to invoke a shell function from a builtin? --BobG
Re: execute_cmd.h is not included in installed headers
On 5/2/22 3:23 PM, Robert E. Griffith wrote: "execute_cmd.h" is not listed in the INSTALLED_HEADERS macro which determines which headers are included for the install-headers target. Yes, builtin commands are generally the target of execution, not things that execute other builtins or shell functions. When builtins execute other commands, it's either something like eval/command/source/exec or the jobs -x/fc type of transform-and-execute. Is it problematic for a loadable builtin to execute shell functions or is it maybe an oversight that that header is not included? If I build against the full source it appears to work fine but I wonder if there are edge cases that cause problems. It's not necessarily an oversight, just not something that builtin commands generally do. What's your use case? -- ``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: execute_cmd.h is not included in installed headers
>> What's your use case? I have a bash script library that supports Objects and Classes in bash script. I am now writing a loadable builtin to speed up the object call and other mechanisms. echo "'$obj'" '_bgclassCall heap_A_X MyClass 0 |' $obj.doSomething p1 p2 _bgclassCall is a function that sets up the method context (e.g. local -n this=heap_A_X), and then calls the shell function that corresponds to 'doSomething' (e.g. MyClass::soSomething) _bgclassCall has a bash implementation but when the new builtin is loaded I suppress the bash version so the builtin is used. It also comes up for example if I want to implement the ConstructObject function as a builtin, it identifies and runs the __constructor shell functions while building up the object instance. --BobG P.S. Here is a longer example of the syntax... Example OO Bash... $ cat /tmp/test.sh #!/usr/bin/env bash source /usr/lib/bg_core.sh import bg_objects.sh ;$L1;$L2 DeclareClass Animal function Animal::__construct() { this[name]="${1:-anonymous}" } function Animal::speak() { echo "${this[name]} says 'generic animal sound'" } DeclareClass Dog : Animal function Dog::speak() { echo "${this[name]} says 'woof'" } DeclareClass Cat : Animal function Cat::speak() { echo "${this[name]} says 'meow'" } declare -A spot; ConstructObject Dog spot "Spot" declare -A whiskers; ConstructObject Cat whiskers "Whiskers" $spot.speak $whiskers.speak $ bash /tmp/test.sh Spot says 'woof' Whiskers says 'meow' On 5/2/22 15:31, Chet Ramey wrote: On 5/2/22 3:23 PM, Robert E. Griffith wrote: "execute_cmd.h" is not listed in the INSTALLED_HEADERS macro which determines which headers are included for the install-headers target. Yes, builtin commands are generally the target of execution, not things that execute other builtins or shell functions. When builtins execute other commands, it's either something like eval/command/source/exec or the jobs -x/fc type of transform-and-execute. Is it problematic for a loadable builtin to execute shell functions or is it maybe an oversight that that header is not included? If I build against the full source it appears to work fine but I wonder if there are edge cases that cause problems. It's not necessarily an oversight, just not something that builtin commands generally do. What's your use case?
Re: execute_cmd.h is not included in installed headers
On 5/2/22 4:03 PM, Robert E. Griffith wrote: >> What's your use case? I have a bash script library that supports Objects and Classes in bash script. I am now writing a loadable builtin to speed up the object call and other mechanisms. echo "'$obj'" '_bgclassCall heap_A_X MyClass 0 |' $obj.doSomething p1 p2 _bgclassCall is a function that sets up the method context (e.g. local -n this=heap_A_X), and then calls the shell function that corresponds to 'doSomething' (e.g. MyClass::soSomething) _bgclassCall has a bash implementation but when the new builtin is loaded I suppress the bash version so the builtin is used. It also comes up for example if I want to implement the ConstructObject function as a builtin, it identifies and runs the __constructor shell functions while building up the object instance. That seems reasonable. I'll add 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: execute_cmd.h is not included in installed headers
>> That seems reasonable. I'll add it. Cool, thanks. --BobG On 5/2/22 16:47, Chet Ramey wrote: On 5/2/22 4:03 PM, Robert E. Griffith wrote: >> What's your use case? I have a bash script library that supports Objects and Classes in bash script. I am now writing a loadable builtin to speed up the object call and other mechanisms. echo "'$obj'" '_bgclassCall heap_A_X MyClass 0 |' $obj.doSomething p1 p2 _bgclassCall is a function that sets up the method context (e.g. local -n this=heap_A_X), and then calls the shell function that corresponds to 'doSomething' (e.g. MyClass::soSomething) _bgclassCall has a bash implementation but when the new builtin is loaded I suppress the bash version so the builtin is used. It also comes up for example if I want to implement the ConstructObject function as a builtin, it identifies and runs the __constructor shell functions while building up the object instance. That seems reasonable. I'll add it.