Re: Bug in documentation (man)

2022-05-02 Thread 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: Bug in documentation (man)

2022-05-02 Thread Gasan
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

2022-05-02 Thread Chet Ramey

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

2022-05-02 Thread Emanuele Torre
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

2022-05-02 Thread Chet Ramey

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

2022-05-02 Thread Jesse Hathaway
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

2022-05-02 Thread Robert E. Griffith
"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

2022-05-02 Thread Chet Ramey

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

2022-05-02 Thread Robert E. Griffith

>> 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

2022-05-02 Thread Chet Ramey

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

2022-05-02 Thread Robert E. Griffith

>> 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.