Re: add custom environment variable in bash source code

[Sam]

> On 18 Aug 2022, at 00:19, b1431736...@163.com wrote:
> 
> Because I'm using Android, Android doesn't support #!/bin/sh and #!/bin/bash, 
> there is a dynamic library that fixes it, so I want to automatically add 
> LD_PRELOAD before starting bash to make this dynamic library work , I want to 
> modify the source code of bash to make it effective, not the bash.bashrc and 
> profile files in the etc directory,what should I do, can you send a video 
> attachment to teach me?
> 

You probably want to edit /etc/ld.so.conf or /etc/ld.so.conf.d/* instead.



signature.asc
Description: Message signed with OpenPGP

Directing to a file...

[sam]

Running program many times I noticed that

ps -p $$ -o pid,args > waiting.$$;
lockfile -1 setting
if ! cat waiting.$$ | egrep -q '[0-9]'
then
ps -p $$ -o pid,args > check.$$
echo "What's going on!!!"
exit 1;
fi


sometimes it prints "What is going on". File 
waiting.1234 contains only ps-headers, that is


  PID COMMAND

while check.1234 contains

PID COMMAND
1234./my_program arg1 arg2


Is this a bug?









--
www.TOTALIZM.com	UFO Earth Occupation 
http://jan-pajak.com/wtc.htm 
http://jan-pajak.com/shuttle.htm 
http://jan-pajak.com/predators.htm



___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: Bash-5.2-alpha available

[Sam James]

> On 22 Jan 2022, at 18:52, Oğuz  wrote:
> 22 Ocak 2022 Cumartesi tarihinde Chet Ramey  yazdı:
>> Because they should behave identically to other forms of quoting that bash
>> handles in here-documents. Why should $'' be different from '' only within
>> here-document bodies?
> Because it'd be useless otherwise. Why would anyone use $'' in a
> here-document other than for embedding escape sequences?

I'm not sure but I'm wondering if this is related to a Gentoo bug
I reported last night when building Binutils with the new Bash alpha.

See https://bugs.gentoo.org/831764#c2 but it seems like it's
related?

Best,
sam



signature.asc
Description: Message signed with OpenPGP

Request for new 5.2 alpha?

[Sam James]

Hi,

Is there a plan for a 2nd 5.2 alpha? A number of reported bugs have been
addressed since and it may help resolve duplicates.

Best,
sam


signature.asc
Description: Message signed with OpenPGP

Crash with 5.2 beta in compgen

[Sam James]

Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: x86_64-pc-linux-gnu-gcc
Compilation CFLAGS: -O2 -pipe -march=native -ggdb3
uname output: Linux 2021-10-24 5.15.34-gentoo-dist-hardened #1 SMP Sat Apr 16 
02:20:51 BST 2022 x86_64 AMD Ryzen 9 3950X 16-Core Processor AuthenticAMD 
GNU/Linux
Machine Type: x86_64-pc-linux-gnu

Bash Version: 5.2
Patch Level: 0
Release Status: beta

Description:
Bash crashes when running compgen -c -X a.

Repeat-By:
   # bash -c "compgen -c -X a"
   Segmentation fault (core dumped)



Originally noticed when running 'eselect compiler-shadow update' in Gentoo 
Linux, but Ionen Wolkens (ionen@g.o) came up with a far smaller reproducer:

# bash -c "compgen -c -X a"
Segmentation fault (core dumped)

Backtrace:
```
Starting program: /bin/bash -c compgen\ -c\ -X\ a
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
__strchr_avx2 () at ../sysdeps/x86_64/multiarch/strchr-avx2.S:65
65  vmovdqu (%rdi), %ymm8
(gdb) bt
#0  __strchr_avx2 () at ../sysdeps/x86_64/multiarch/strchr-avx2.S:65
#1  0x555c618f in quote_word_break_chars (text=0x5565f300 
"/usr/local/sbin/.keep") at bashline.c:4143
#2  bash_quote_filename (s=s@entry=0x5565f2c0 "/usr/local/sbin/.keep", 
rtype=rtype@entry=1, qcp=qcp@entry=0x7fffdbbf "") at bashline.c:4346
#3  0x555c73f5 in executable_completion (searching_path=1, 
filename=0x5565f2c0 "/usr/local/sbin/.keep") at bashline.c:1951
#4  command_word_completion_function (hint_text=0x55613bff "", state=83) at 
bashline.c:2378
#5  0x77f77257 in rl_completion_matches (text=text@entry=0x55613bff 
"", entry_function=0x555c6d70 )
at 
/usr/src/debug/sys-libs/readline-8.2_beta/readline-8.2-beta/complete.c:2219
#6  0x555d00ef in gen_action_completions 
(text=text@entry=0x55613bff "", cs=, cs=) at 
pcomplete.c:856
#7  0x555d02f1 in gen_compspec_completions (cs=cs@entry=0x55655860, 
cmd=cmd@entry=0x556130b0 "compgen", word=word@entry=0x55613bff "", 
start=start@entry=0,
end=end@entry=0, foundp=foundp@entry=0x0) at pcomplete.c:1333
#8  0x555ebab1 in compgen_builtin (list=) at 
./complete.def:721
#9  0x55579f7b in execute_builtin (builtin=builtin@entry=0x555eb7f0 
, words=words@entry=0x55655510, flags=flags@entry=64, 
subshell=subshell@entry=0)
at execute_cmd.c:4958
#10 0x5557fec1 in execute_builtin_or_function (flags=64, 
fds_to_close=0x556551a0, redirects=0x0, var=0x0, builtin=0x555eb7f0 
, words=0x55655510)
at execute_cmd.c:5472
#11 execute_simple_command (fds_to_close=0x556551a0, async=, 
pipe_out=, pipe_in=, 
simple_command=0x55655080) at execute_cmd.c:4724
#12 execute_command_internal (command=0x55655050, 
asynchronous=asynchronous@entry=0, pipe_in=pipe_in@entry=-1, 
pipe_out=pipe_out@entry=-1, fds_to_close=fds_to_close@entry=0x556551a0)
at execute_cmd.c:866
#13 0x555d8c99 in parse_and_execute (string=, 
from_file=from_file@entry=0x555fd09f "-c", flags=flags@entry=20) at 
evalstring.c:519
#14 0x55565650 in run_one_command (command=0x7fffe4fe "compgen -c 
-X a") at shell.c:1473
#15 0x55563f0d in main (argc=3, argv=0x7fffe268, 
env=0x7fffe288) at shell.c:763
```

Let me know if I need to grab more information.


signature.asc
Description: Message signed with OpenPGP

Re: Crash with 5.2 beta in compgen

[Sam James]

> On 16 Apr 2022, at 17:11, Chet Ramey  wrote:
> 
> On 4/16/22 1:45 AM, Sam James wrote:
> 
>> Bash Version: 5.2
>> Patch Level: 0
>> Release Status: beta
>> Description:
>> Bash crashes when running compgen -c -X a.
>> Repeat-By:
>># bash -c "compgen -c -X a"
>>Segmentation fault (core dumped)
> 
> I can't reproduce this. I wonder if it has to do with resource limits.
> 

Suspect Andreas' reply may be more insightful, but was able to reproduce this 
in a fresh Debian stable chroot too,
created with debootstrap.

root@debian-stable:~/bash-5.2-beta# /usr/local/bin/bash -c "compgen -c -X a"
Segmentation fault (core dumped)


signature.asc
Description: Message signed with OpenPGP

bash 5.1 heredoc pipes problematic, shopt needed

[Sam Liddicott]

Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -g -O2 -flto=auto -ffat-lto-objects -flto=auto
-ffat-lto-objects -fstack-protector-strong -Wformat -Werror=format-security
-Wall
uname output: Linux junior 5.15.0-25-generic #25-Ubuntu SMP Wed Mar 30
15:54:22 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu

Bash Version: 5.1
Patch Level: 16
Release Status: release

Description:
Listed in the changes:
c. Here documents and here strings now use pipes for the expanded
   document if it's smaller than the pipe buffer size, reverting
   to temporary files if it's larger.

This causes problems with many programs suffering from the TOCTOU
bug of checking whether or not the input is actually a file
instead of just using it as one.

e.g. "repo" tool performs in manifest_xml.py:

  if not os.path.isfile(path):
raise ManifestParseError('manifest %s not found' % name)

This bug is clearly in repo and (these other tools) and certainly is
not bash's fault but there is going to be a lot of breakage with the
short and medium term remedy to downgrade to bash 5.0

I *like* that files aren't needed any more but there are decades
of scripts integrating with tools than make such checks, and which
work on the unknown accidental assumption that heredocs are files.

Repeat-By:
python2 -c 'import os; print(os.path.isfile("/dev/fd/3"))' 3<<

Re: bash 5.1 heredoc pipes problematic, shopt needed

[Sam Liddicott]

For the record, here is my bash workaround to convert a heredoc fd into a
tmpfile.
Code golfers - please feel free to simplify it

Just prefix the command with "herefile" and the fd that needs converting to
a file,
e.g.
  herefile 3 command ... /dev/fd/3  3<<&'"$2" &&
# run command reading from file via specific fd but closed tmp file
eval '"${@:5}"' "$4<&$1" "$1<&-" "$2<&-"
# remember exit code and fd's to close
set -- "$1" "$2" "$?"
# finally close the tmp files cos bash doesn't do it for you if you
name them
eval exec "$1<&-" "$2<&-"
# return saved exit code
return "$3"
   } {_}<"$2" # open tmp file into _ and save at the top of the block
  } {_}>"$1" # open tmp file into _ and save at the top of the block
}

# tests without the herefile fix
$ python2 -c 'import os; print(os.path.isfile("/dev/fd/3"))' 3<< /dev/pts/1
lrwx-- 1 sliddicott sliddicott 64 Apr 22 16:12 1 -> /dev/pts/1
lrwx-- 1 sliddicott sliddicott 64 Apr 22 16:12 2 -> /dev/pts/1
lr-x-- 1 sliddicott sliddicott 64 Apr 22 16:12 3 -> 'pipe:[170069]'
lr-x-- 1 sliddicott sliddicott 64 Apr 22 16:12 4 -> /proc/17483/fd

# tests with
$ herefile 3 python2 -c 'import os; print(os.path.isfile("/dev/fd/3"))'
3<< /dev/pts/1
lrwx-- 1 sliddicott sliddicott 64 Apr 22 16:05 1 -> /dev/pts/1
lrwx-- 1 sliddicott sliddicott 64 Apr 22 16:05 2 -> /dev/pts/1
lr-x-- 1 sliddicott sliddicott 64 Apr 22 16:05 3 ->
'/tmp/tmp.rkDXYvp4hn (deleted)'
lr-x-- 1 sliddicott sliddicott 64 Apr 22 16:05 4 -> /proc/16519/fd

On Fri, 22 Apr 2022 at 14:51, Sam Liddicott  wrote:
>
> Configuration Information [Automatically generated, do not change]:
> Machine: x86_64
> OS: linux-gnu
> Compiler: gcc
> Compilation CFLAGS: -g -O2 -flto=auto -ffat-lto-objects -flto=auto
-ffat-lto-objects -fstack-protector-strong -Wformat -Werror=format-security
-Wall
> uname output: Linux junior 5.15.0-25-generic #25-Ubuntu SMP Wed Mar 30
15:54:22 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
> Machine Type: x86_64-pc-linux-gnu
>
> Bash Version: 5.1
> Patch Level: 16
> Release Status: release
>
> Description:
> Listed in the changes:
> c. Here documents and here strings now use pipes for the expanded
>document if it's smaller than the pipe buffer size, reverting
>to temporary files if it's larger.
>
> This causes problems with many programs suffering from the TOCTOU
> bug of checking whether or not the input is actually a file
> instead of just using it as one.
>
> e.g. "repo" tool performs in manifest_xml.py:
>
>   if not os.path.isfile(path):
> raise ManifestParseError('manifest %s not found' % name)
>
> This bug is clearly in repo and (these other tools) and certainly
is
> not bash's fault but there is going to be a lot of breakage with
the
> short and medium term remedy to downgrade to bash 5.0
>
> I *like* that files aren't needed any more but there are decades
> of scripts integrating with tools than make such checks, and which
> work on the unknown accidental assumption that heredocs are files.
>
> Repeat-By:
> python2 -c 'import os; print(os.path.isfile("/dev/fd/3"))' 3<<
> emits True for bash 5.0 and before but emits False for bash 5.1
>
> Fix:
> Please could we at least have a shopt to maintain the old
behaviour?
>
>
>

Re: bash 5.1 heredoc pipes problematic, shopt needed

[Sam Liddicott]

Thanks for that important context.

Chet Ramey once said:
> One can argue that the concerns on either side (seeking on stdin vs.
> assuming that here-strings will never hit the file system) are assumptions
> that should not be made,

In reality no-one is making such an assumption, neither idea enters their
head, nor do they assume anything about whether a called program will or
will not redundantly stat the "file" name to check that it is a file.

What they do assume is that what worked with bash 5.0 will keep working
with minor revision 5.1

This is going to keep coming up.

Sam

On Sun, 24 Apr 2022, 21:11 Lawrence Velázquez,  wrote:

> > On Apr 24, 2022, at 3:41 PM, Oğuz  wrote:
> >
> > 24 Nisan 2022 Pazar tarihinde Ángel  yazdı:
> >>
> >> 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.
> >>
> >
> > https://lists.gnu.org/archive/html/bug-bash/2020-12/msg00084.html
>
>
> Oh yeah, I remember this.  Here is Chet's position at the time:
>
> https://lists.gnu.org/archive/html/bug-bash/2020-12/msg00085.html
>
>
> Begin forwarded message:
>
> > From: Chet Ramey 
> > Subject: Re: Is there a way to force here-documents/strings to use
> temporary files?
> > Date: December 20, 2020 at 3:53:32 PM EST
> > To: Oğuz , bug-bash 
> > Cc: chet.ra...@case.edu
> > Reply-To: chet.ra...@case.edu
> >
> > On 12/20/20 2:25 AM, Oğuz wrote:
> >
> >> So, is there any way to force here-documents to use temporary files no
> >> matter how long the expanded document is? If not, it would be nice if
> >> compat50 had this effect.
> >
> > There is not. I'm not sure that a compat setting would be appropriate for
> > something that is purely an implementation issue.
> >
> > There was a fairly extensive discussion that preceded this change,
> starting
> > with
> >
> > https://lists.gnu.org/archive/html/bug-bash/2019-03/msg00073.html
> >
> > and continuing the next month (!) with
> >
> > https://lists.gnu.org/archive/html/bug-bash/2019-04/msg7.html
> >
> > One can argue that the concerns on either side (seeking on stdin vs.
> > assuming that here-strings will never hit the file system) are
> assumptions
> > that should not be made, for instance
> >
> > https://lists.gnu.org/archive/html/bug-bash/2019-03/msg00075.html
> > or
> > https://lists.gnu.org/archive/html/bug-bash/2019-03/msg00082.html
> >
> > I decided ultimately to make the change for the most common cases, where
> > the amount of data passed in a here string or here document is small. But
> > that is simply an implementation detail; the documented semantics of
> here-
> > documents and here-strings aren't changed.
> >
> > --
> > ``The lyf so short, the craft so long to lerne.'' - Chaucer
> >``Ars longa, vita brevis'' - Hippocrates
> > Chet Ramey, UTech, CWRUc...@case.edu
> http://tiswww.cwru.edu/~chet/
>
>
> --
> vq

Re: bash 5.1 heredoc pipes problematic, shopt needed

[Sam Liddicott]

On Mon, 25 Apr 2022, 22:03 Chet Ramey,  wrote:

> On 4/22/22 9:51 AM, Sam Liddicott wrote:
>
> >  Please could we at least have a shopt to maintain the old
> behaviour?
>
> Let's start with making it part of BASH_COMPAT=50.
>

Thanks- that's great.

Sam


> --
> ``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.2 official patch 9

[Sam James]

> On 14 Nov 2022, at 20:03, Chet Ramey  wrote:
> 
> On 11/12/22 4:39 AM, Kerin Millar wrote:
>> On Tue, 8 Nov 2022 09:50:51 -0500
>> Chet Ramey  wrote:
>>> BASH PATCH REPORT
>>> =
>>> 
>>> Bash-Release: 5.2
>>> Patch-ID: bash52-009
>> Are there any plans to backport the "fixes for extended glob in compat mode" 
>> in the near future?
> 
> What is the "near future?" I have a patch that will probably be part of
> the next batch (attached if you want to use it). There's only been the one
> report of a problem, though, which impacts its priority.

Thanks, I'll backport it in Gentoo now. Being part of the next batch is helpful
to know.




signature.asc
Description: Message signed with OpenPGP

UBSAN error in lib/sh/random.c:79

[Sam James]

Hi folks,

I'm currently testing common Linux userland with UndefinedBehaviorSanitizer 
(UBSAN, -fsanitize=undefined).

With Bash 5.2_p15, I get the following with this script:
```
$ cat /tmp/guess_suffix
guess_suffix() {
tmpdir="${TMPDIR}"/.ecompress$$.${RANDOM}
}
guess_suffix
```

It seems easier to trigger if I run it as an external script rather than as a 
function in an interactive
shell.

```
$ export UBSAN_OPTIONS="print_stacktrace=1:halt_on_error=1"
$ bash -x /tmp/guess_suffix
+ guess_suffix
random.c:79:21: runtime error: signed integer overflow: 31789 * 127773 cannot 
be represented in type 'int'
#0 0x559791a301ce in intrand32 
/usr/src/debug/app-shells/bash-5.2_p15/bash-5.2/lib/sh/random.c:79
#1 0x559791a301ce in brand 
/usr/src/debug/app-shells/bash-5.2_p15/bash-5.2/lib/sh/random.c:106
#2 0x5597918cde5c in get_random_number 
/usr/src/debug/app-shells/bash-5.2_p15/bash-5.2/variables.c:1436
#3 0x5597918cde5c in get_random 
/usr/src/debug/app-shells/bash-5.2_p15/bash-5.2/variables.c:1448
#4 0x5597918d0021 in find_variable 
/usr/src/debug/app-shells/bash-5.2_p15/bash-5.2/variables.c:2425
#5 0x55979194a881 in parameter_brace_expand_word 
/usr/src/debug/app-shells/bash-5.2_p15/bash-5.2/subst.c:7514
#6 0x559791939783 in parameter_brace_expand 
/usr/src/debug/app-shells/bash-5.2_p15/bash-5.2/subst.c:9845
#7 0x559791939783 in param_expand 
/usr/src/debug/app-shells/bash-5.2_p15/bash-5.2/subst.c:10538
#8 0x559791941732 in expand_word_internal 
/usr/src/debug/app-shells/bash-5.2_p15/bash-5.2/subst.c:11236
#9 0x5597919487b8 in call_expand_word_internal 
/usr/src/debug/app-shells/bash-5.2_p15/bash-5.2/subst.c:4325
#10 0x5597919487b8 in expand_string_assignment 
/usr/src/debug/app-shells/bash-5.2_p15/bash-5.2/subst.c:4423
#11 0x559791935c27 in expand_string_if_necessary 
/usr/src/debug/app-shells/bash-5.2_p15/bash-5.2/subst.c:3855
#12 0x5597919365c3 in do_assignment_internal 
/usr/src/debug/app-shells/bash-5.2_p15/bash-5.2/subst.c:3587
#13 0x55979190e40b in do_assignment_statements 
/usr/src/debug/app-shells/bash-5.2_p15/bash-5.2/subst.c:12898
#14 0x559791952269 in expand_word_list_internal 
/usr/src/debug/app-shells/bash-5.2_p15/bash-5.2/subst.c:12978
#15 0x559791952269 in expand_words 
/usr/src/debug/app-shells/bash-5.2_p15/bash-5.2/subst.c:12280
#16 0x5597918be644 in execute_simple_command 
/usr/src/debug/app-shells/bash-5.2_p15/bash-5.2/execute_cmd.c:4506
#17 0x5597918be644 in execute_command_internal 
/usr/src/debug/app-shells/bash-5.2_p15/bash-5.2/execute_cmd.c:866
#18 0x5597918bce56 in execute_command_internal 
/usr/src/debug/app-shells/bash-5.2_p15/bash-5.2/execute_cmd.c:1033
#19 0x5597918c5e7b in execute_function 
/usr/src/debug/app-shells/bash-5.2_p15/bash-5.2/execute_cmd.c:5242
#20 0x5597918bf4d4 in execute_builtin_or_function 
/usr/src/debug/app-shells/bash-5.2_p15/bash-5.2/execute_cmd.c:5487
#21 0x5597918bf4d4 in execute_simple_command 
/usr/src/debug/app-shells/bash-5.2_p15/bash-5.2/execute_cmd.c:4737
#22 0x5597918bf4d4 in execute_command_internal 
/usr/src/debug/app-shells/bash-5.2_p15/bash-5.2/execute_cmd.c:866
#23 0x5597918c13bb in execute_command 
/usr/src/debug/app-shells/bash-5.2_p15/bash-5.2/execute_cmd.c:413
#24 0x559791879fac in reader_loop 
/usr/src/debug/app-shells/bash-5.2_p15/bash-5.2/eval.c:171
#25 0x559791877463 in main 
/usr/src/debug/app-shells/bash-5.2_p15/bash-5.2/shell.c:833
#26 0x7f3c001c5289  (/usr/lib64/libc.so.6+0x23289)
#27 0x7f3c001c5344 in __libc_start_main (/usr/lib64/libc.so.6+0x23344)
#28 0x559791878590 in _start (/usr/bin/bash.self+0x13e590)
```

This is on x86_64-pc-linux-gnu with GCC 13.0.0_pre20230101.

Best,
sam


signature.asc
Description: Message signed with OpenPGP

[PATCH] aclocal.m4: fix -Wimplicit-function-declaration in dup2 check

[Sam James]

dup2 requires a  include. Fixes the following when diffing config.log
 when testing with a stricter compiler:
```
-warning: call to undeclared function 'dup2'; ISO C99 and later do not support 
implicit function declarations [-Wimplicit-function-declaration]
+error: call to undeclared function 'dup2'; ISO C99 and later do not support 
implicit function declarations [-Wimplicit-function-declaration]
```
---
 aclocal.m4 | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/aclocal.m4 b/aclocal.m4
index cc97bd4b..25e20fc2 100644
--- a/aclocal.m4
+++ b/aclocal.m4
@@ -238,6 +238,9 @@ AC_CACHE_VAL(bash_cv_dup2_broken,
 #include 
 #include 
 #include 
+#ifdef HAVE_UNISTD_H
+#include 
+#endif
 int
 main()
 {
-- 
2.39.1

Re: [PATCH] aclocal.m4: fix -Wimplicit-function-declaration in dup2 check

[Sam James]

> On 2 Feb 2023, at 05:46, Sam James  wrote:
> 
> dup2 requires a  include. Fixes the following when diffing 
> config.log
> when testing with a stricter compiler:
> ```
> -warning: call to undeclared function 'dup2'; ISO C99 and later do not 
> support implicit function declarations [-Wimplicit-function-declaration]
> +error: call to undeclared function 'dup2'; ISO C99 and later do not support 
> implicit function declarations [-Wimplicit-function-declaration]
> ```
> ---
> aclocal.m4 | 3 +++
> 1 file changed, 3 insertions(+)
> 
> diff --git a/aclocal.m4 b/aclocal.m4
> index cc97bd4b..25e20fc2 100644
> --- a/aclocal.m4
> +++ b/aclocal.m4
> @@ -238,6 +238,9 @@ AC_CACHE_VAL(bash_cv_dup2_broken,
> #include 
> #include 
> #include 
> +#ifdef HAVE_UNISTD_H
> +#include 
> +#endif
> int
> main()
> {
> --
> 2.39.1
> 
> 

ping - this should be trivial and fixes some real issues Gentoo and Fedora have 
hit when
doing modern C porting (https://wiki.gentoo.org/wiki/Modern_C_porting,
https://fedoraproject.org/wiki/Changes/PortingToModernC).

Best,
sam


signature.asc
Description: Message signed with OpenPGP

Re: Bash not portable to C23

[Sam James]

Paul Eggert  writes:

> On 3/23/23 18:23, Lawrence Velázquez wrote:
>> On Thu, Mar 23, 2023, at 9:16 PM, Paul Eggert wrote:
>>> I see that Bash won't compile with a C23 compiler, since it still uses
>>> old-style function definitions which C23 no longer supports. Is there
>>> any effort and/or interest in fixing this portability problem in Bash?
>> I believe this was done a few months ago on the devel branch.
>> https://git.savannah.gnu.org/cgit/bash.git/commit/?h=devel&id=a61ffa78ede6df4d1127fddd2e8a1a77a7186ea1
>
> Oh, thanks, I was looking at the wrong branch.
>
> However, Bash's devel branch still has old-style function definitions
> and therefore won't compile with a strict C23 compiler. For example,
> get_variable_value in variables.c is old-style. I assume there would
> be interest in fixing remaining areas where Bash won't port to C23?

I hope so. I'm waiting for a review of an issue in one of its configure
checks with a strict compiler too [0].

[0] https://lists.gnu.org/archive/html/bug-bash/2023-02/msg0.html


signature.asc
Description: PGP signature

Re: Bash not portable to C23

[Sam James]

Chet Ramey  writes:

> On 3/24/23 1:23 AM, Sam James wrote:
>
>> I hope so. I'm waiting for a review of an issue in one of its configure
>> checks with a strict compiler too [0].
>> [0]
>> https://lists.gnu.org/archive/html/bug-bash/2023-02/msg0.html
>
> Sorry, I missed that one.

No worries & thanks :)

best,
sam


signature.asc
Description: PGP signature

Re: [PATCH] Pacify gcc -Wpointer-to-int-cast

[Sam James]

Paul Eggert  writes:

> * lib/sh/random.c (genseed): Use a different type, to pacify GCC
> "warning: cast from pointer to integer of different size
> [-Wpointer-to-int-cast]" on platforms with 64-bit pointers
> and 32-bit int.

Thanks for this one. I've been meaning to report it because
-Wpointer-to-int-cast is one of the warnings we flag up in our
packaging in Gentoo, as it often indicates a portability problem.



signature.asc
Description: PGP signature

posix_spawn (or vfork) support?

[Sam James]

Hi,

Sorry if this has come up before - I did take a look and couldn't find
anything.

Could bash use posix_spawn/vfork instead of the rather heavyweight
fork?

I'm aware of the work in `devel` to add nofork comsubs which is very
intriguing, but I do wonder about another suggestion: could bash use
posix_spawn (or maybe vfork directly) in some cases?

Recently, we've been optimising a lot of our global-scope (commonly used
bash "libraries") used for packages in Gentoo and unsurprisingly, a lot
of the cost has been down to forks, so this came up.

(It also came up a few years ago in 
https://trofi.github.io/posts/215-perf-and-dwarf-and-fork.html).

Some prior art:
* fish used to do it, but stopped because it didn't make as much sense
for them (fish is for interactive use AFAIK so I guess the environment
size is never big enough for this to pay off): 
https://github.com/fish-shell/fish-shell/issues/3149.

* ksh does it (https://github.com/ksh93/ksh/issues/79).

* The `posixspawn` utility (https://github.com/AlexanderOMara/posixspawn) aims 
to make this
available as a tool to call rather than something builtin.

* https://blog.famzah.net/tag/benchmark-fork/ has an interesting set of
benchmarks.

* https://metacpan.org/pod/Proc::FastSpawn implements this in Perl
with some interesting discussion on the performance benefits.

best,
sam


signature.asc
Description: PGP signature

Re: Enable compgen even when programmable completions are not available?

[Sam James]

alex xmb ratchev  writes:

> On Mon, Jun 26, 2023, 11:55 alex xmb ratchev  wrote:
>
>>[snip]
> u also really dont need eval at all
>
> by the way , what does this nonsense code supposed to do
>> separate between vars for future list / deletement ?

If you read the linked bug, you'd find out.

Re: Enable compgen even when programmable completions are not available?

[Sam James]

Chet Ramey  writes:

> On 6/29/23 11:16 PM, Eli Schwartz wrote:
>
>> I assume that, given the option exists in the configure script, there
>> are people who will want to use the option made available to them. One
>> reason might be because they are configuring it for a system that isn't
>> fussed about using bash for an interactive shell (either it is
>> administrated via non-interactive means, or simply because the preferred
>> interactive site shell is e.g. zsh). In such cases, a rationale that
>> readily comes to mind is "this user wanted a smaller, leaner bash binary
>> by disabling unimportant bits that they do not use".
>
> Maybe. I don't think it's that big a win.
>
>> And because this is conditional on readline, which is usually an
>> external library dependency (a global system policy decision), reducing
>> the number of shared libraries the dynamic loader has to deal with might
>> be especially interesting.
>
> The dynamic loader has to know where the library is. If you don't call
> readline, it shouldn't ever have to actually map it into the process.

I think it still has to map it even with lazy binding, but I'm not
really worried about this point much.
>
>> (This is all theorizing -- I quite like bash as an interactive shell
>> and
>> have no intention of building systems with readline disabled. It is
>> nonetheless true that the topic came up because there are Gentoo users
>> who apparently decided to try to do so.)
>
> Yes, but the question is whether or not that makes sense in the modern age,
> and whether there should be extra features to accommodate that decision.
>
>
>> The thing is, does it really matter? I think there's a larger issue
>> here, which I mentioned in the Gentoo bug report but probably makes
>> sense to copy/paste here:
>
>
>> 
>>> The problem with compgen is that it is only available for use when
>>> bash is configured with --enable-progcomp / --enable-readline, which
>>> feels like a powerful argument that script authors are not allowed to
>>> assume that it will exist, regardless of how useful it may be in
>>> non-programmable-completion contexts.
>>>
>>> Maybe the answer is to ask that it always be available as a builtin,
>>> even when the programmable completion system isn't enabled.
>
> But this isn't right. You have to explicitly disable those configuration
> options -- they're on by default. You don't have to do anything to get
> readline support compiled into bash. You have to do things to disable it.
> If you take that extra configuration step to disable it, there are going
> to be consequences.
>

There's a few open questions here:
1. Is the inconsistency between functions and variables desirable here?
(i.e. functions being something we can handle via `declare`, but
variables needing `compgen`?)

2. Is something on-by-default enough of a signal that you should rely
on it being available? Can I suggest editing the configure help text
to make clear you strongly recommend it be enabled?

3. On the Gentoo side, why do we need to turn it off while bootstrapping
prefix? I strongly suspect we can at least fall back to the bundled bash
readline for bootstrapping purposes and this isn't a problem in reality
anymore, but I'll check.


>> So: can I? Are my bash scripts valid scripts if they use compgen, or
>> should I be concerned that when I publish them for wide adoption, people
>> are going to report bugs to me that it is broken on their niche system
>> configuration which they are positive they have a good reason for?
>
> You can always check whether compgen is available and fall back to some
> other solution if it's not.
>
> compgen -v >/dev/null 2>&1 && have_compgen=1
>
>> Should I document in the project readme that in addition to needing
>> a
>> certain minimum version of bash, "you also need to make sure that
>> programmable completions are enabled when compiling your bash binary"?
>
> No. You need to say that users should make sure they haven't disabled
> them when compiling their bash binary.
>

Then the configure help text should reflect that. But needing compgen
for this is still odd, in any case. Or feels it to me.

>> Should I eschew compgen and rely on eval-using hacks like the one Kerin
>> described?
>
> It's your call, of course. You just have to decide whether or not it's
> worth the effort to accommodate non-default option choices. What about
> aliases? Arrays? Brace expansion? Process substitution? Extglobs? All of
> those can be compiled out. What's the `bash core' you're going to assume?

Only one of these requires an external (modulo the bundled copy) library.

BASH_SUBSHELL documentation misleading

[Sam Liddicott]

Configuration Information [Automatically generated, do not change]:
Machine: i686
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS:  -DPROGRAM='bash' -DCONF_HOSTTYPE='i686' 
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i686-pc-linux-gnu' 
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DP$ uname output: 
Linux sojo 2.6.35-28-generic-pae #49-Ubuntu SMP Tue Mar 1 14:58:06 UTC 
2011 i686 GNU/Linux

Machine Type: i686-pc-linux-gnu

Bash Version: 4.1
Patch Level: 5
Release Status: release

Description:
man page says:

BASH_SUBSHELL
  Incremented by one each time a subshell or subshell  
environment

  is spawned.  The initial value is 0.

This suggests that:

echo $BASH_SUBSHELL ; ( echo ) ; echo $BASH_SUBSHELL

would not give the same answer for BASH_SUBSHELL

Fix:
As it behaves more like a depth counter than a serial number
maybe it should say

BASH_SUBSHELL
  Incremented by one in each nested subshell or subshell 
evironment.

  It is always 0 when $BASH_PID=$$

Re: BASH_SUBSHELL documentation misleading

[Sam Liddicott]

On 23/03/11 18:52, Chris F.A. Johnson wrote:


On Wed, 23 Mar 2011, Sam Liddicott wrote:



Configuration Information [Automatically generated, do not change]:
Machine: i686
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS:  -DPROGRAM='bash' -DCONF_HOSTTYPE='i686' 
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i686-pc-linux-gnu' 
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DP$ uname output: 
Linux sojo 2.6.35-28-generic-pae #49-Ubuntu SMP Tue Mar 1 14:58:06 
UTC 2011 i686 GNU/Linux

Machine Type: i686-pc-linux-gnu

Bash Version: 4.1
Patch Level: 5
Release Status: release

Description:
   man page says:

   BASH_SUBSHELL
 Incremented by one each time a subshell or subshell 
environment

 is spawned.  The initial value is 0.

   This suggests that:

   echo $BASH_SUBSHELL ; ( echo ) ; echo $BASH_SUBSHELL

   would not give the same answer for BASH_SUBSHELL


   No, it suggests that:

echo $BASH_SUBSHELL ; ( echo $BASH_SUBSHELL )

   would not give the same answer for BASH_SUBSHELL


It should suggest that, because that is how it actually works.

But the man page is misleading and does not actually suggest this.



   In your example, the second "echo $BASH_SUBSHELL" is at the same
   depth as the first.



Yes. But a new subshell environment has been spawned. Each time that 
happens BASH_SUBSHELL should increase.


Of course I know how it does work, but the man page isn't clear. It 
doesn't say that the increase is only visible within the subshell and 
therefore it is a measurement of subshell depth.


Sam

Re: BASH_SUBSHELL documentation misleading

[Sam Liddicott]

On 23/03/11 20:32, Maarten Billemont wrote:


On 23 Mar 2011, at 21:28, Chet Ramey wrote:


OK.  What wording would you like to see?

I don't mind the wording he proposed:


On 23 Mar 2011, at 17:12, Sam Liddicott wrote:

maybe it should say

BASH_SUBSHELL
  Incremented by one in each nested subshell or subshell evironment.
  It is always 0 when $BASH_PID=$$



Yup, that's what I would like to see.

Sam

Re: A Feature Request for History

[Sam Steingold]

> * Chet Ramey  [2011-06-13 15:26:27 -0400]:
>
> On 6/13/11 1:10 PM, Bradley M. Kuhn wrote:
>
>> The only feature you describe above missing with that configuration is
>> that existing shells won't find history commands written out
>> in-between.  I have a tendency to close/open bash shells, so I don't run
>> into that problem.
>> 
>> Unfortunately, having looked recently at the history code, I think
>> adding a feature whereby existing running shells "notice" the history
>> file has changed would be a large rewrite to the history code.  I think
>> that would be a useful optional feature, though.
>
> People have had success using `history -a' and `history -n' to
> accomplish this.  The idea is to append your latest command to some
> common history file, then use history -n to read other shells'
> commands into your history list.

Please add this to the bash FAQ (especially the appropriate concomitant
settings for histappend et al)!
This has been discussed in many places and various conflicting advice
has been given, including using "history -a; history -r;" which seems to
explode the history file and bash processes:
here is my current top:

29475 sds   25   0  240m 171m 1344 R 100.1  1.4  15:58.20 bash
10482 sds   25   0  231m 162m 1336 R 100.1  1.4  16:24.99 bash
24588 sds   25   0  230m 161m 1340 R 99.7  1.3  13:21.40 bash

$ gdb -p 29475
(gdb) where
#0  0x00481f89 in add_history ()
#1  0x00484d15 in read_history_range ()
#2  0x0045e0c9 in history_builtin ()
#3  0x00428386 in ?? ()
#4  0x004299d7 in ?? ()
#5  0x0042a784 in execute_command_internal ()
#6  0x0042caa4 in ?? ()
#7  0x0042a857 in execute_command_internal ()
#8  0x0042ba5f in execute_command ()
#9  0x0042ca6d in ?? ()
#10 0x0042a857 in execute_command_internal ()
#11 0x0045bd40 in parse_and_execute ()
#12 0x00422fb7 in execute_variable_command ()
#13 0x0041b4ef in parse_command ()
#14 0x0041b5c6 in read_command ()
#15 0x0041b74e in reader_loop ()
#16 0x0041b2aa in main ()
(gdb) 
(same tree for all of them!)

also, is there some internal bash locking which would prevent different
bash processes from writing history at the same time?
there should be!

thanks.

-- 
Sam Steingold (http://sds.podval.org/) on CentOS release 5.6 (Final) X 
11.0.60900031
http://thereligionofpeace.com http://ffii.org http://camera.org
http://openvotingconsortium.org http://memri.org http://truepeace.org
I haven't lost my mind -- it's backed up on tape somewhere.

Re: A Feature Request for History

[Sam Steingold]

> * Sam Steingold  [2011-08-03 11:12:42 -0400]:
>
> here is my current top:
>
> 29475 sds   25   0  240m 171m 1344 R 100.1  1.4  15:58.20 bash
> 10482 sds   25   0  231m 162m 1336 R 100.1  1.4  16:24.99 bash
> 24588 sds   25   0  230m 161m 1340 R 99.7  1.3  13:21.40 bash

1. this is outrageous, there should be a (settable) time limit on 
PROMPT_COMMAND.

2. (unrelated) in addition to timestamp, history file should also
contain the struct rusage from wait4().

-- 
Sam Steingold (http://sds.podval.org/) on CentOS release 5.6 (Final) X 
11.0.60900031
http://iris.org.il http://mideasttruth.com http://honestreporting.com
http://jihadwatch.org http://www.memritv.org http://dhimmi.com
Three can keep a secret if two of them are dead.

delete matching entries from history

[Sam Steingold]

how do I delete matching entries from bash history?
every other line in the file is "#time" so I cannot use the simple grep.

-- 
Sam Steingold (http://sds.podval.org/) on CentOS release 5.6 (Final) X 
11.0.60900031
http://dhimmi.com http://camera.org http://memri.org
http://thereligionofpeace.com http://www.memritv.org
Bug free software merely has random features.

Re: test -nt not sane

[Sam Steingold]

> * Curtis Doty  [2011-08-10 11:53:52 -0700]:
>
> They have identical mtimes (as set by touch)--i.e. the directory is
> *not* newer than the symlink--but it still outputs "yes". Why?

mtime for a symlink comes from stat(), not stat().
anything is newer than a non-existent object.

-- 
Sam Steingold (http://sds.podval.org/) on CentOS release 5.6 (Final) X 
11.0.60900031
http://truepeace.org http://memri.org http://openvotingconsortium.org
http://www.PetitionOnline.com/tap12009/ http://camera.org http://ffii.org
Isn't "Microsoft Works" an advertisement lie?

conditional aliases are broken

[Sam Steingold]

this works:

$ alias z='echo a'
$ zz(){ z b; }
$ zz
a b

however, after sourcing this file:
if true; then
  alias z='echo a'
  zz(){ z b; }
fi

I get
$ zz
bash: z: command not found
$ type -a z
z is aliased to `echo a'

i.e., somehow zz is defined as function calling z, and z is defined as
an alias, but zz does not know what z is an alias.

-- 
Sam Steingold (http://sds.podval.org/) on CentOS release 5.6 (Final) X 
11.0.60900031
http://pmw.org.il http://dhimmi.com http://ffii.org http://palestinefacts.org
http://iris.org.il http://mideasttruth.com http://memri.org
Those who can laugh at themselves will never cease to be amused.

Re: conditional aliases are broken

[Sam Steingold]

> * Andreas Schwab  [2011-08-15 18:42:30 +0200]:
>
> Sam Steingold  writes:
>
>> this works:
>>
>> $ alias z='echo a'
>> $ zz(){ z b; }
>> $ zz
>> a b
>>
>> however, after sourcing this file:
>> if true; then
>>   alias z='echo a'
>>   zz(){ z b; }
>> fi
>
> Aliases are expanded during reading, but the alias command isn't
> executed until after the complete compound command was read.

Cool.  Now, what does this imply?
Is this the expected behavior aka "feature"?


-- 
Sam Steingold (http://sds.podval.org/) on CentOS release 5.6 (Final) X 
11.0.60900031
http://mideasttruth.com http://palestinefacts.org http://truepeace.org
http://iris.org.il http://www.PetitionOnline.com/tap12009/
Apathy Club meeting this Friday.  If you want to come, you're not invited.

Re: conditional aliases are broken

[Sam Steingold]

> * Andreas Schwab  [2011-08-15 22:04:04 +0200]:
>
> Sam Steingold  writes:
>
>> Cool.  Now, what does this imply?
>
>"For almost every purpose, shell functions are preferred over aliases."

so, how do I write

alias a=b

as a function?
(remember that arguments may contain spaces &c)

-- 
Sam Steingold (http://sds.podval.org/) on CentOS release 5.6 (Final) X 
11.0.60900031
http://mideasttruth.com http://camera.org http://pmw.org.il
http://iris.org.il http://ffii.org http://thereligionofpeace.com
A poet who reads his verse in public may have other nasty habits.

Re: conditional aliases are broken

[Sam Steingold]

> * Eric Blake  [2011-08-15 16:59:29 -0600]:
>
> On 08/15/2011 04:40 PM, Sam Steingold wrote:
>>> * Andreas Schwab  [2011-08-15 22:04:04 +0200]:
>>>
>>> Sam Steingold  writes:
>>>
>>>> Cool.  Now, what does this imply?
>>>
>>> "For almost every purpose, shell functions are preferred over aliases."
>>
>> so, how do I write
>>
>> alias a=b
>>
>> as a function?
>> (remember that arguments may contain spaces&c)
>
> a() { b "$@"; }

mkdir z
cd z
touch a b 'c d'

how do I write a function that would print the same as
$ \ls | cat
a
b
c d
$


$ f1(){ for a in "$*"; do echo $a; done; }
$ f1 *
a b c d
$

$ f2(){ for a in $*; do echo $a; done; }
$ f2 *
a
b
c
d
$


-- 
Sam Steingold (http://sds.podval.org/) on CentOS release 5.6 (Final) X 
11.0.60900031
http://ffii.org http://honestreporting.com http://www.memritv.org
http://thereligionofpeace.com http://mideasttruth.com http://dhimmi.com
UNIX is a way of thinking.  Windows is a way of not thinking.

variables set on command line

[Sam Steingold]

CYGWIN_NT-5.2-WOW64 sds 1.7.9(0.237/5/3) 2011-03-29 10:10 i686 Cygwin
BASH_VERSION='4.1.10(4)-release'

at the bash prompt I observe this:
$ f(){ echo a=$a b=$b c=$c ; }
$ unset a b c
$ a=a b=b f
a=a b=b c=
$ f
a= b= c=
which I believe is correct (i.e., variables set in "a=a b=b f" are unset
after f terminates).

alas, when I call /bin/sh on the same machine, I see this:

f(){ echo a=$a b=$b c=$c ; }
f
a= b= c=
a=a b=b f
a=a b=b c=
f
a=a b=b c=
exit

i.e., variables set in "a=a b=b f" survive to the next command.
$ /bin/sh --version
GNU bash, version 4.1.10(4)-release (i686-pc-cygwin)

is this the expected behavior?

thanks.

-- 
Sam Steingold (http://sds.podval.org/) on CentOS release 5.6 (Final) X 
11.0.60900031
http://palestinefacts.org http://openvotingconsortium.org http://memri.org
http://www.PetitionOnline.com/tap12009/ http://dhimmi.com
He who laughs last thinks slowest.

Re: variables set on command line

[Sam Steingold]

> * Eric Blake  [2011-08-24 09:31:45 -0600]:
>> f(){ echo a=$a b=$b c=$c ; }
>> f
>> a= b= c=
>> a=a b=b f
>> a=a b=b c=
>> f
>> a=a b=b c=
>
> Which is indeed correct under the rules for POSIX

This sucks big time.
So if I want to bind a variable for an eval invocation and do this:

  eval "`./libtool --tag=CC --config | grep '^archive_cmds='`"
  CC='${CC}' libobjs='$libs' deplibs='${CLFLAGS}' compiler_flags='${CFLAGS}' \
soname='$dll' lib='$lib' output_objdir='$dyndir' \
eval XCC_CREATESHARED=\"${archive_cmds}\"

and I want CC to have an old value after the second eval, I need to save
it and restore it by hand, like this:

  CC_save=$CC
  CC='${CC}' libobjs='$libs' deplibs='${CLFLAGS}' compiler_flags='${CFLAGS}' \
soname='$dll' lib='$lib' output_objdir='$dyndir' \
eval XCC_CREATESHARED=\"${archive_cmds}\"
  CC=$CC_save

however, this does not distinguish between unset CC and CC=''.
(is there a way to distinguish these two situations?)

thanks!

-- 
Sam Steingold (http://sds.podval.org/) on CentOS release 5.6 (Final) X 
11.0.60900031
http://ffii.org http://palestinefacts.org http://honestreporting.com
http://thereligionofpeace.com http://openvotingconsortium.org http://dhimmi.com
Abandon all hope, all ye who press Enter.

RE: pwd as first command changes script behavior

[Quiring, Sam]

Hi Jonathan,

Thanks for taking the time.  I get it now.  I am sorry to have bothered you

-Sam

-Original Message-
From: Jonathan Nieder [mailto:jrnie...@gmail.com] 
Sent: Thursday, September 01, 2011 2:27 PM
To: Quiring, Sam
Cc: bug-bash@gnu.org; b...@packages.debian.org
Subject: Re: pwd as first command changes script behavior

Hi Sam,

Quiring, Sam wrote:

> #! /bin/bash
> pwd
> echo $_
>
> #! /bin/bash
> echo $_
> pwd
>
> The first one displays:
> /home/windriver/changes/NexS-235r1/with-camera
> pwd
>
> The second one displays:
> ./apply.sh
> /home/windriver/changes/NexS-235r1/with-camera

That's what $_ is advertised to do: it expands to the last
argument to the previous command, after expansion (or the full
pathname to the shell or shell script if there was no previous
command).  You're probably looking for $(which $0) or something
similar.

Hope that helps,
Jonathan

pwd as first command changes script behavior

[Quiring, Sam]

Configuration Information [Automatically generated, do not change]: Machine: 
x86_64 OS: linux-gnu Compiler: gcc Compilation
CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' -DCONF_OSTYPE='linux-gnu' 
-DCONF_MACHTYPE='x86_64-pc-linux-gnu'
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL 
-DHAVE_CONFIG_H -I.  -I../bash -I../bash/include
-I../bash/lib -g -O2 -Wall uname output: Linux pdx-squiri-u2tb 
2.6.32-30-generic #59-Ubuntu SMP Tue Mar 1 21:30:46 UTC 2011
x86_64 GNU/Linux Machine Type: x86_64-pc-linux-gnu

Bash Version: 4.1 Patch Level: 5 Release Status: release

Description:
 I have two similiar scripts:
#! /bin/bash
pwd
echo $_

#! /bin/bash
echo $_
pwd

The first one displays:
/home/windriver/changes/NexS-235r1/with-camera
pwd

The second one displays:
./apply.sh
/home/windriver/changes/NexS-235r1/with-camera


Repeat-By:
See Description

fd leak with {fd}>

[Sam Liddicott]

Repeated executions of: { echo $fd ; } {fd}> /dev/null
will emit different numbers, indicating that fd is not closed when the
block completes.


As an interesting aside it seems not to be possible to close the FD within
the block either:

{ echo $fd ; eval exec "$fd>&-" ; } {fd}> /dev/null

Re: fd leak with {fd}>

[Sam Liddicott]

On Thu, Nov 22, 2012 at 7:15 PM, Chet Ramey  wrote:

> On 11/16/12 10:47 AM, Sam Liddicott wrote:
> > Repeated executions of: { echo $fd ; } {fd}> /dev/null
> > will emit different numbers, indicating that fd is not closed when the
> > block completes.
>
> This is intentional.  Having been given a handle to the file descriptor,
> the shell programmer is assumed to be able to manage it himself.
>
> > As an interesting aside it seems not to be possible to close the FD
> within
> > the block either:
> >
> > { echo $fd ; eval exec "$fd>&-" ; } {fd}> /dev/null
>
> But this is not.  There should be a way to ensure the fd's survival while
> allowing it to be closed within the block.  I will fix this for the next
> version.
>

It may well be closed within the block; I meant to state that externally it
was visible despite the internal close.

So this is probably a double no-bug

thanks for your attention

Sam

Re: fd leak with {fd}>

[Sam Liddicott]

On Mon, Nov 26, 2012 at 1:49 PM, Pierre Gaston wrote:

>
>
> On Mon, Nov 26, 2012 at 3:41 PM, Pierre Gaston wrote:
>
>>
>>
>> On Mon, Nov 26, 2012 at 3:37 PM, Chet Ramey  wrote:
>>
>>> On 11/23/12 2:04 AM, Pierre Gaston wrote:
>>>
>>> > It seems rather counter intuitive that the fd is not closed after
>>> leaving
>>> > the block.
>>> > With the normal redirection the fd is only available inside the block
>>> >
>>> > $ { : ;} 3>&1;echo bar >&3
>>> > -bash: 3: Bad file descriptor
>>> >
>>> > if 3 is closed why should I expect {fd} to be still open?
>>>
>>> Because that's part of the reason to have {x}: so the user can handle the
>>> disposition of the file descriptor himself.
>>
>> .
>> I don't see any difference between 3> and {x}> except that the later free
>> me from the hassle of avoid conflicting fd
>>
>
> It seems that ksh93 behaves just like bash in this regard
> Well, as I don't use it I don't really care, but I vote for this as a bug
> as I fail to see the benefit of this behavior as i find it useless and not
> consistent with the normal redirection.
>
>

And also potentially renders the feature useless.

I had hours of debugging why my {fd} >( ... ) co-processes were not
terminating. A less tenacious user would give up on either {fd} or >( ... )
or both

For users to actually USE these features, the principle of least surprise
should be followed.

Ironically I was changing from my own method of allocating fd's (
http://blog.sam.liddicott.com/2012/03/local-variables-are-great.html) to
the simple "bash do it for me" and things broke because they didn't work
like anything similar in bash.

I would expect: exec {fd}>( ... }
to keep the descriptor open. if the user wants that he can do:
{ exec {fd}>... ; ... ; }
if he wants it to be closed when the scope ends he will do:
{ ... ; } {fd}>...

So I think this surprising behaviour adds nothing that wasn't there
already, and nothing that the user expects and also adds things that the
user will not expect

Sam

Re: fd leak with {fd}>

[Sam Liddicott]

On Mon, Nov 26, 2012 at 5:02 PM, Chet Ramey  wrote:

> On 11/26/12 9:26 AM, Sam Liddicott wrote:
>
> > It seems that ksh93 behaves just like bash in this regard
> > Well, as I don't use it I don't really care, but I vote for this as a
> > bug as I fail to see the benefit of this behavior as i find it
> useless
> > and not consistent with the normal redirection.
> >
> >
> >
> > And also potentially renders the feature useless.
>
> OK, so how does a misunderstanding in how a feature works render it
> useless?  Maybe better documentation is enough to make the features
> clear.
>

I explained how in the lines of my response that you deleted.

It is potentially useless because:

1. it is non-obvious, most users will not expect this behaviour (unless
already initiated into the secret) and so will not try to get that benefit.
2. it is an unexpected side effect and will do something which is not
expected, and be widely and "wrongly" labelled as buggy or unreliable by
misunderstanding users and therefore damage the bash reputation.
3. there already exists simple and explicit way to get the supposed benefit
using the existing mechanism "exec"

Certainly better documentation is required as a defense against the wrong
understanding being given, but users will still not expect this subtle
different and will not naturally fall to this interpretation or expect
therefore that there is any need to read the documentation.

I fear that the better documentation merely will serve as an excuse for
unexpected behaviour of a confusing and not-needed side-feature of an
important feature.

Sam

Re: fd leak with {fd}>

[Sam Liddicott]

On Tue, Nov 27, 2012 at 7:08 AM, Pierre Gaston wrote:

>
>
> On Mon, Nov 26, 2012 at 10:48 PM, Chet Ramey  wrote:
>
>> On 11/26/12 12:11 PM, Sam Liddicott wrote:
>> > 3. there already exists simple and explicit way to get the supposed
>> benefit
>> > using the existing mechanism "exec"
>>
>> Not quite.  You still have to pick the file descriptor you want to use
>> with
>> `exec'.  But you are not being forced to use it -- by all means, if you
>> think it's not what you need or want, feel free to avoid it and encourage
>> your friends to do the same.  There have been unsuccessful new features --
>> the case-modifying expansions are one example of a swing and miss.
>>
>
> You seem to say that there are 2 aspects of this new feature, giving
>  control on the fd
> and letting the system choose the number.
>
> Let's see the first aspect, you are saying that leaving the fd open doing
> "{ : } {fd}>file"
> is a feature to let the user control the file descriptor.
>
> But why would one use this when you can do:
>
> exec {fd}>file
>
> That is there is already exec to answer the problem of letting the user
> manage the fd,
> Why would you use another new, non intuitive non consistent feature?
>

Precisely so! Who would feel the need for this (mis-)feature. Anyone who
wants to control the persistence of the fd will use exec. No-one will feel
the need for { : ; } {fd}>file or expect that it could even work!

I would expect to be able to use { : ; } {fd}>/dev/null as a nasty idiom to
find a free descriptor number, I could not have expected it to leave the
descriptor open.

And in fact to emphasise the unexpected nature, it damages the concept of
compound commands:

# will not leave fd open
sleep 5 {fd}>/dev/null

# will not leave fd open
( sleep 5 )  {fd}>/dev/null

 # will leave fd open
{ sleep 5 ; } {fd}>/dev/null

Can it be expected that using { } as an incremental edit to a script
(because an extra command needs inserted with the same IO) should leave the
descriptor dangling, but not if ( ) is used?

If too many parts of the documentation will need annotating with exceptions
it indicates a wrong expression of the feature.

For me having bashing assigning the fd number solves another problem.
>

For me too. It is a great feature. Heavenly!

But because that was not the only problem it "solved" I spent a few hours
tracking down what my problem was and isolated this behaviour.
Then I checked the documentation and saw that there was no remark to excuse
or explain this behaviour and filed a bug. Note that documentation would
have prevented me from filing a bug. It would not have helped me avoid
wasting time. I had to already track down the problem completely in order
to realise it was related to this feature.

So in short, as keeping the fd open is available through exec from ancient
times, and as it would be unexpected here, I think it is an
un-necessary confusion.

Sam

readline & signals

[Sam Steingold]

when clisp is built with readline, sending clisp sigterm puts into
background:

$ clisp -x '(unwind-protect (sleep 100) (print "cleanup"))' &
$ kill %1
[1]+  Stopped ...
$ fg
Exiting on signal 15

"cleanup"
Bye.
$

when readline is not compiled in:

$ clisp -x '(unwind-protect (sleep 100) (print "cleanup"))' &
$ kill %1
Exiting on signal 15

"cleanup"
Bye.
$

we do not call rl_set_signals() (we need to handle most signals ourselves).
we do call rl_resize_terminal() from our own sigwinch handler.

so, what are we doing wrong?

thanks!

-- 
Sam Steingold (http://www.podval.org/~sds) running w2k
<http://www.jihadwatch.org/> <http://pmw.org.il/> <http://www.iris.org.il>
<http://www.mideasttruth.com/> <http://www.palestinefacts.org/>
Even Windows doesn't suck, when you use Common Lisp



___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

sigsegv in rl_resize_terminal

[Sam Steingold]

I get this:

Program received signal SIGSEGV, Segmentation fault.
0x2821e472 in rl_resize_terminal () from /usr/lib/libreadline.so.4

(FreeBSD x86-freebsd1 4.11-RELEASE FreeBSD 4.11-RELEASE #0: Wed Oct  5 21:16:58 
PDT 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC  i386)

what are the rules for invoking rl_resize_terminal?
do I need to call rl_initialize() or readline() before rl_resize_terminal?

-- 
Sam Steingold (http://www.podval.org/~sds) running w2k
<http://www.palestinefacts.org/> <http://www.savegushkatif.org>
<http://www.openvotingconsortium.org/> <http://www.camera.org>
Linux - find out what you've been missing while you've been rebooting Windows.



___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: sigsegv in rl_resize_terminal

[Sam Steingold]

> * Chet Ramey <[EMAIL PROTECTED]> [2005-10-16 17:53:39 -0400]:
>
> Sam Steingold wrote:
>> I get this:
>> 
>> Program received signal SIGSEGV, Segmentation fault.
>> 0x2821e472 in rl_resize_terminal () from /usr/lib/libreadline.so.4
>> 
>> (FreeBSD x86-freebsd1 4.11-RELEASE FreeBSD 4.11-RELEASE #0: Wed Oct  5 
>> 21:16:58 PDT 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC  i386)
>> 
>> what are the rules for invoking rl_resize_terminal?
>> do I need to call rl_initialize() or readline() before rl_resize_terminal?
>
> Certainly rl_intialize at least, and readline to avoid unexpected and
> bizarre output, since rl_resize_terminal calls the display code.

is there a way to check whether readline has been initialized already?
e.g., clisp may be running interactively and using readline and it may
be running in the batch mode and not using readline (so when the
SIGWINCH handler is called, readline has not been initialized).
what is TRT?

thanks!

-- 
Sam Steingold (http://www.podval.org/~sds) running w2k
<http://ffii.org/> <http://www.memri.org/>
<http://www.savegushkatif.org> <http://www.iris.org.il> <http://www.camera.org>
Bill Gates is not god and Microsoft is not heaven.



___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: sigsegv in rl_resize_terminal

[Sam Steingold]

> * Chet Ramey <[EMAIL PROTECTED]> [2005-10-16 22:38:38 -0400]:
>
> Sam Steingold wrote:
>>>* Chet Ramey <[EMAIL PROTECTED]> [2005-10-16 17:53:39 -0400]:
>>>
>>>Sam Steingold wrote:
>
>> 
>> is there a way to check whether readline has been initialized already?
>> e.g., clisp may be running interactively and using readline and it may
>> be running in the batch mode and not using readline (so when the
>> SIGWINCH handler is called, readline has not been initialized).
>
> The rl_readline_state variable has the RL_INITIALIZED bit set after
> initialization.

thanks a lot!
Do I understand correctly that

 #if defined(HAVE_READLINE) && defined(RL_ISSTATE) && defined(RL_INITIALIZED)
  if (RL_ISSTATE(RL_INITIALIZED))
rl_resize_terminal();
 #endif

is the right way to do that?
Thanks!

-- 
Sam Steingold (http://www.podval.org/~sds) running w2k
<http://www.honestreporting.com> <http://www.palestinefacts.org/>
<http://www.openvotingconsortium.org/> <http://www.jihadwatch.org/>
Your mouse pad is incompatible with MS Windows - your HD will be reformatted.


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Bash is broken

[Overdorf, Sam]

The following does not work on my computers:

 

If [ "1" > "2" ]

  then

echo "greater"

  else

echo "not greater"

fi

 

Bash thinks this is I/O redirection and creates a file by the name of
"2" in my directory.

This should be a string compare.

 

Thanks,

Sam

 

___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

rfe: auto-timing

[Sam Steingold]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I would like all long-running commands to be auto-timed.
i.e., all commands I type at the prompt should be run as if with "time"
built-in, but if the real or user time is smaller than some value
(specified by the user in an environment variable), the timing output
should be omitted.
keeping the timing of every command costs essentially nothing, so this
may even simplify the code.
an extension of the idea is to keep this timing information in the
history so that one could look up timings for previous commands.

thanks
Sam.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHXsrfPp1Qsf2qnMcRAk2xAKCLcvqaGM8yzHcmvrmSODlDfh32hACgh2uI
+G/9fA5DIdL9afUfXapRITY=
=O0Ny
-END PGP SIGNATURE-

Re: time command

[Sam Steingold]

Francis Litterio wrote:

Eric Blake wrote:


According to Yu Cha Yung on 6/23/2008 12:24 AM:
|time ls > time.txt
|It doesnt show the information of time in time.txt.

That's because in bash, time is a reserved word, and because time's output
goes to stderr, not stdout.


[...]


\time ls >time.txt 2>&1


Or use Bash's builtin "command" command, like this:

command time ls >time.txt 2>&1


shameless plug:


Subject: rfe: auto-timing

I would like all long-running commands to be auto-timed.
i.e., all commands I type at the prompt should be run as if with "time"
built-in, but if the real or user time is smaller than some value
(specified by the user in an environment variable), the timing output
should be omitted.
keeping the timing of every command costs essentially nothing, so this
may even simplify the code.
an extension of the idea is to keep this timing information in the
history so that one could look up timings for previous commands.

Re: time command

[Sam Steingold]

Chuck Swiger wrote:

On Jun 24, 2008, at 7:47 AM, Sam Steingold wrote:

I would like all long-running commands to be auto-timed.
i.e., all commands I type at the prompt should be run as if with "time"
built-in, but if the real or user time is smaller than some value
(specified by the user in an environment variable), the timing output
should be omitted.


In ZSH, that's obtainable via the REPORTTIME env variable:

REPORTTIME
   If nonnegative, commands whose combined user and  system  execu-
   tion  times  (measured  in  seconds) are greater than this value
   have timing statistics printed for them.


yes, this is what I want in bash.
also, the timings should be saved in the history files.

readline/history cvs?

[Sam Steingold]

Where is the readline/history cvs (or git or whatever) repository?
to keep the clisp readline module up to date with the current 
readline/history releases, I would like to be able to get a diff between 
readline.h & history.h from readline 5.0 and readline 5.2.

how do I get those diffs (without downloading the full tag.gz packages)?
thanks!

how to get out of the vi editing mode

[Sam Steingold]

I hit something by accident and command line editing no longer works.
(I think I switched to the vi mode).
1. how do I get back to the emacs mode? (aka what did I hit?!)
2. how do I disable vi mode forever and ever (short of recompiling bash myself)?

thanks.

-- 
Sam Steingold (http://sds.podval.org/) on Ubuntu 9.04 (jaunty)
http://mideasttruth.com http://palestinefacts.org http://ffii.org
http://thereligionofpeace.com http://pmw.org.il http://dhimmi.com
Perl: all stupidities of UNIX in one.

how to keep newlines in ``

[Sam Steingold]

this:
foo=`ls`
echo $foo
will print files in one line even though ls prints them with newlines.
is there a way to preserve newlines in the above echo?
thanks.

leaks fd for internal functions but not external command

[Sam Liddicott]

Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS:  -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu'
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL
-DHAVE_CONFIG_H   -I.  -I../. -I.././include -I.././lib  -Wdate-time
-D_FORTIFY_SOURCE=2 -g -O2
-fdebug-prefix-map=/build/bash-N2nMjo/bash-4.4.18=.
-fstack-protector-strong -Wformat -Werror=format-security -Wall
-Wno-parentheses -Wno-format-security
uname output: Linux sojo 4.15.0-54-generic #58-Ubuntu SMP Mon Jun 24
10:55:24 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu

Bash Version: 4.4
Patch Level: 20
Release Status: release

Description:
Bash redirection sequence cases a file descriptor to be leaked
if the main command is an internal function but not if it is
an external command.

Based on prior conversation, I suspect it is supposed to leak
in the internal case (though that is annoying) but it is
inconsistent that it does not for the external case.

Repeat-By:
bash -c is used to get a pure environment for test

The perl-esque 'line noise' {_}>&2 2>&1 1>&${_} {_}<&-
is to swap stdout with stderr while providing no other
fd for any invoked processes to hang on to.

(Yes _ is abused)

test 1: leaks fd 10 for internal echo

bash -c 'echo 1 {_}>&2 2>&1 1>&${_} {_}<&- ;
echo done ; lsof -p $$ | grep CHR'

test 2: does not leak fd for external /bin/echo

bash -c '/bin/echo 1 {_}>&2 2>&1 1>&${_} {_}<&- ;
echo done ; lsof -p $$ | grep CHR'

test 3: does not leak if fd 10 is used explicitly

bash -c 'echo 1 10>&2 2>&1 1>&10 10<&- ;
echo done ; lsof -p $$ | grep CHR'

Re: leaks fd for internal functions but not external command

[Sam Liddicott]

On Tue, 23 Jul 2019 at 16:05, Chet Ramey  wrote:

> On 7/23/19 10:33 AM, Sam Liddicott wrote:
>
> > Bash Version: 4.4
> > Patch Level: 20
> > Release Status: release
> >
> > Description:
> > Bash redirection sequence cases a file descriptor to be leaked
> > if the main command is an internal function but not if it is
> > an external command.
>
> It's not `leaked': you have a handle on it and can manipulate it as you
> wish.
>

evidently not, it got closed for me with /bin/echo so I couldn't use it as
I wish


> > Based on prior conversation, I suspect it is supposed to leak
> > in the internal case (though that is annoying) but it is
> > inconsistent that it does not for the external case.
>
> It's set to close-on-exec. If you want to use it in a child process,
> you have a handle that you can use to dup to another fd.
>

The report concerns the different behaviour with internal and external
operations.

Sam

Re: leaks fd for internal functions but not external command

[Sam Liddicott]

On Tue, 23 Jul 2019 at 16:13, Chet Ramey  wrote:

> On 7/23/19 11:11 AM, Sam Liddicott wrote:
>
> > The report concerns the different behaviour with internal and external
> > operations.
>
> Right. The close-on-exec is deliberate. That's how it was intended.
>

Doesn't close-on-exec usually takes effect only on the process that does
the exec?
i.e. the fork that does the exec, not the parent process?

Sam

Re: leaks fd for internal functions but not external command

[Sam Liddicott]

On Tue, 23 Jul 2019 at 16:15, Sam Liddicott  wrote:

>
>
> On Tue, 23 Jul 2019 at 16:13, Chet Ramey  wrote:
>
>> On 7/23/19 11:11 AM, Sam Liddicott wrote:
>>
>> > The report concerns the different behaviour with internal and external
>> > operations.
>>
>> Right. The close-on-exec is deliberate. That's how it was intended.
>>
>
> Doesn't close-on-exec usually takes effect only on the process that does
> the exec?
> i.e. the fork that does the exec, not the parent process?
>

It got closed in the parent. The lsof is running for the parent, the main
process. /bin/echo has quit before the lsof runs.

Re: leaks fd for internal functions but not external command

[Sam Liddicott]

On Tue, 23 Jul 2019 at 16:35, Chet Ramey  wrote:

> On 7/23/19 11:20 AM, Sam Liddicott wrote:
> >
> > On Tue, 23 Jul 2019 at 16:15, Sam Liddicott  > <mailto:s...@liddicott.com>> wrote:
> >
> >
> >
> > On Tue, 23 Jul 2019 at 16:13, Chet Ramey  > <mailto:chet.ra...@case.edu>> wrote:
> >
> > On 7/23/19 11:11 AM, Sam Liddicott wrote:
> >
> > > The report concerns the different behaviour with internal and
> > external
> > > operations.
> >
> > Right. The close-on-exec is deliberate. That's how it was
> intended.
> >
> >
> > Doesn't close-on-exec usually takes effect only on the process that
> > does the exec?
> > i.e. the fork that does the exec, not the parent process?
> >
> >
> > It got closed in the parent. The lsof is running for the parent, the main
> > process. /bin/echo has quit before the lsof runs.
>
> You mean case 2 in your original post? That's because redirections are
> performed in the child process forked to run /bin/echo, so the fd never
> exists in the parent process. I thought you were talking about case 1,
> with the builtin echo.
>

No doubt, but this report concerns the inconsistency.

Is using {xxx}>... suppose to give me a file handle I can use as I wish (as
you say), or not?

Using explicit descriptors e.g. 10>... behaves consistently whether the the
command is internal or external.

Having bash allocate the descriptor is not consistent.

Sam

Re: leaks fd for internal functions but not external command

[Sam Liddicott]

On Tue, 23 Jul 2019 at 16:45, Chet Ramey  wrote:

> On 7/23/19 11:40 AM, Sam Liddicott wrote:
> >
> > On Tue, 23 Jul 2019 at 16:35, Chet Ramey  > <mailto:chet.ra...@case.edu>> wrote:
> >
> > On 7/23/19 11:20 AM, Sam Liddicott wrote:
> >     >
> > > On Tue, 23 Jul 2019 at 16:15, Sam Liddicott  > <mailto:s...@liddicott.com>
> > > <mailto:s...@liddicott.com <mailto:s...@liddicott.com>>> wrote:
> > >
> > >
> > >
> > > On Tue, 23 Jul 2019 at 16:13, Chet Ramey  > <mailto:chet.ra...@case.edu>
> > > <mailto:chet.ra...@case.edu <mailto:chet.ra...@case.edu>>>
> wrote:
> > >
> > > On 7/23/19 11:11 AM, Sam Liddicott wrote:
> > >
> > > > The report concerns the different behaviour with
> internal and
> > > external
> > > > operations.
> > >
> > > Right. The close-on-exec is deliberate. That's how it was
> > intended.
> > >
> > >
> > > Doesn't close-on-exec usually takes effect only on the process
> that
> > > does the exec?
> > > i.e. the fork that does the exec, not the parent process?
> > >
> > >
> > > It got closed in the parent. The lsof is running for the parent,
> the main
> > > process. /bin/echo has quit before the lsof runs.
> >
> > You mean case 2 in your original post? That's because redirections
> are
> > performed in the child process forked to run /bin/echo, so the fd
> never
> > exists in the parent process. I thought you were talking about case
> 1,
> > with the builtin echo.
> >
> >
> > No doubt, but this report concerns the inconsistency.
> >
> > Is using {xxx}>... suppose to give me a file handle I can use as I wish
> (as
> > you say), or not?
>
> So the difference is between cases 1 and 3? That's the difference between
> using the {var} syntax and using an explicit file descriptor.
>

Given what you have explained as intentional, it the difference between 1
and 2, but it is best understood as a 4-way difference, outlined here:

1. {var} internal: fd remains open in parent
2. {var} external: fd closed in parent
3. numeric internal: fd closed in parent
4. numeric external: fd closed in parent

1. {var} internal: fd remains open in parent
bash -c 'echo 1 {_}>&2 2>&1 1>&${_} {_}<&- ;
echo done ; lsof -p $$ | grep CHR'

2. {var} external: fd closed in parent
bash -c '/bin/echo 1 {_}>&2 2>&1 1>&${_} {_}<&- ;
echo done ; lsof -p $$ | grep CHR'

3. numeric internal: fd closed in parent
bash -c 'echo 1 10>&2 2>&1 1>&10 10<&- ;
echo done ; lsof -p $$ | grep CHR'

4. numeric external: fd closed in parent
bash -c '/bin/echo 1 10>&2 2>&1 1>&10 10<&- ;
echo done ; lsof -p $$ | grep CHR'

You've indicated that {var} syntax leaves me an fd to do with what I wish.

You've also explained what bash is doing that makes this untrue if the
command was an external command.

I don't believe that this behaviour is *intended( to depend on the
non-obvious detail of whether or not the command is external.

Given the coding pattern of wrapping external commands with functions that
re-invoke using bash "command"; this can lead to unpredictable behaviours
when such wrappers are active.

e.g. openssl() { LD_LIBRARY_PATH="$LD_LIBRARY_PATH:/extra" *command*
openssl "$@"; }

If that function is defined, I get a handle leak*, if it isn't and main
openssl is called, I don't -- or from the other of view my handle got
closed without my knowledge, so I can't use it as I wish.

Personally I would wish that "{var} internal" would also close the fd as it
does for numeric fd and for external {var} fd, because if I really wanted
to open an fd and have it hang around I would do a naked: exec {xxx}>&2 ;
type of thing.

I also think that based on your description of what bash is doing, it might
be easier to fix by also closing in the parent, as I describe.

It would bring full consistency and avoid hard to detect and hard to
code-around bugs.

Ultimately, unless {var} external is intended to behave different to {var}
internal, then we have a consistency bug.
If it is intended to be different, then we have a documentation bug, this
intended inconsistency would need documenting.

Sam

Re: leaks fd for internal functions but not external command

[Sam Liddicott]

I'm very surprised that you continue to insist that it should be a *design*
decision that it should be hard for a script writer to be able to tell if a
handle will be left open or not.

What could be the rationale for such a design decision?

The vague justification you provide "there are plenty of things that depend
on whether or not a command is builtin, or whether it's run in the parent
shell" is true but more relevant to an implementation constraint than a
design decision.

I'm confident that most of these things you hint at are too *avoid* the
scripter needing to be aware of the difference between internal and
external commands.

A design decision may well be to leave a variable handle open, but what
*design* decision would add the proviso that it not be an external command?

I stress that the notable comparisons are not between 1 and 3; but between
1 and 2 or between 2 and 4.

Sam

On Tue, 23 Jul 2019, 21:57 Chet Ramey,  wrote:

> On 7/23/19 12:12 PM, Sam Liddicott wrote:
>
> > Given what you have explained as intentional, it the difference between 1
> > and 2, but it is best understood as a 4-way difference, outlined here:
> >
> > 1. {var} internal: fd remains open in parent
> > 2. {var} external: fd closed in parent
> > 3. numeric internal: fd closed in parent
> > 4. numeric external: fd closed in parent
> >
> > 1. {var} internal: fd remains open in parent
> > bash -c 'echo 1 {_}>&2 2>&1 1>&${_} {_}<&- ;
> > echo done ; lsof -p $$ | grep CHR'
> >
> > 2. {var} external: fd closed in parent
> > bash -c '/bin/echo 1 {_}>&2 2>&1 1>&${_} {_}<&- ;
> > echo done ; lsof -p $$ | grep CHR'
> >
> > 3. numeric internal: fd closed in parent
> > bash -c 'echo 1 10>&2 2>&1 1>&10 10<&- ;
> > echo done ; lsof -p $$ | grep CHR'
> >
> > 4. numeric external: fd closed in parent
> > bash -c '/bin/echo 1 10>&2 2>&1 1>&10 10<&- ;
> > echo done ; lsof -p $$ | grep CHR'
> >
> > You've indicated that {var} syntax leaves me an fd to do with what I
> wish.
>
> Yes. The question is whether the {_}<&- should close the file descriptor
> `permanently' or whether that close action should be undone because you're
> not using `exec' and the file descriptor was created using the variable
> assignment syntax. The latter is what bash does now.
>
> > You've also explained what bash is doing that makes this untrue if the
> > command was an external command.
>
> Because you never open the file descriptor in the parent shell:
> redirections happen in the child. The child process in case 2 (and 4)
> can do what it wants with the file descriptor, and its view of the
> file descriptor is the same as case 1 (and 3).
>
> > I don't believe that this behaviour is *intended( to depend on the
> > non-obvious detail of whether or not the command is external.
>
> Why? There are plenty of things that depend on whether or not a command is
> builtin, or whether it's run in the parent shell.
>
> >
> > Given the coding pattern of wrapping external commands with functions
> that
> > re-invoke using bash "command"; this can lead to unpredictable behaviours
> > when such wrappers are active.
> >
> > e.g. openssl() { LD_LIBRARY_PATH="$LD_LIBRARY_PATH:/extra" *command*
> > openssl "$@"; }
> >
> > If that function is defined, I get a handle leak*, if it isn't and main
> > openssl is called, I don't -- or from the other of view my handle got
> > closed without my knowledge, so I can't use it as I wish.
> >
> > Personally I would wish that "{var} internal" would also close the fd as
> it
> > does for numeric fd and for external {var} fd, because if I really wanted
> > to open an fd and have it hang around I would do a naked: exec {xxx}>&2 ;
> > type of thing.
>
> Sure. But there's not as good a reason to have that syntax otherwise. It's
> just syntactic sugar, a way for historical shells to use file descriptors
> greater than 9.
>
> > I also think that based on your description of what bash is doing, it
> might
> > be easier to fix by also closing in the parent, as I describe.
> >
> > It would bring full consistency and avoid hard to detect and hard to
> > code-around bugs.
> >
> > Ultimately, unless {var} external is intended to behave different to
> {var}
> > internal, then we have a consistency bug.
>
> The internal/external difference doesn

Re: leaks fd for internal functions but not external command

[Sam Liddicott]

Thanks for that thoughtful response.

* I understand that the design decision is to have variable file
descriptors to stay open after per-command redirection
* I understand that implementation constraints make it impossible to do
this uniformly (for external command redirection)
* I understand that it is difficult for the script author to detect which
case his code will be

I'm trying to make bash better and more usable.

The shell normally does a great job of hiding the difference between
internal and external commands, so even though it's very well documented,
most of the time the user doesn't need to be aware. This is great for the
user, and according to the principle of least surprise.

The syntactic sugar of having bash select a free fd (which necessary for
good composability of operations in complex script pipelines) is a great
benefit, especially when mixing with older pipelines having fixed numeric
fd.

You say that there are technical reasons why the syntactic sugar of also
keeping the fd open can't be implemented uniformly.

I wonder if this puts unnecessary cognitive burden on the user, leading to
reluctance to get the benefits, or to the introduction of latent bugs.

There is a case I explain below which can lead to a leaked fd being held on
to by subsequently invoked external processes. Of course it will
technically be the users fault but I'm looking at reducing the cognitive
burdens that make such a fault ultimately inevitable.

The cognitive burdens of leaving the fd open are:

1. It breaks the normal expectation that per-command redirects are limited
to the scope of the command.

A naked exec already works to hold open a variable fd in a wider scope if
that's what the scripter actually wants: exec {fd}>... ;

2. As syntactic sugar it moves, not removes, the boiler-plate burden

This naked exec (see above) saved by the syntactic sugar in the case where
the fd should remain open is offset by the naked exec now required in order
to close the fd for the traditional case that the fd should not left open
beyond the scope of the command.

3. The unmeetable cognitive burden is that in order to safely manage the
previous two item, the user needs to know if the command will be external
or internal or a function.

This makes it hard for the user depend on this feature, because it is not
possible to be sure at script author time whether a command is external. It
may have become a function, (due to export -f, source, etc) which affect
the execution environment.

4. The inevitable propagation of leaked fd's

The knowing user can remember to always use an identity wrapper function to
force treatment as external commands as internal functions in order to get
uniform behaviour, and also explicitly close the fd afterwards. (I hope
this doesn't break exec optimisations or signal propagation over a
different process tree topology, though I doubt it.

But other users may not know to close the fd which was never apparent (due
invoking an external command) but which becomes an fd leak when they
combine with other bash features (functions wrapping of external commands,
or export -f environment that does this unawares) and those leaked fd's may
then be inherited by other invoked external processes which may hold on to
them for some time.

This contrived example minimises the pipeline fd contortions in order to
show that when what was an external command then becomes an internal
command, it can as a consequence result in an fd leak to external processes
(bash+lsof+grep here) which may be long lived.

stty {x}>/tmp/log
bash -c 'lsof -p $$ | grep log ; :'
stty() {
  command stty $EXTRA_STTY "$@"
}
stty {x}>/tmp/log
bash -c 'lsof -p $$ | grep log ; :'

Leading to questions like: "Why does wrapping a one command in a function
cause a different background process to hang on to a private handle not
even used there?"

The future:

I recognise what you say about past design decisions, but for the future,
as it is hard to safely get the benefit of leaving the handle open for
variable per-command redefines, even for users who know about it, I wonder
if the syntactic sugar might be redefined to reduce the cognitive burden
and widen the benefit for the most valued variable fd's feature.

If the variable fd syntactic sugar were re-designed so that variable
handles were also limited to the scope the command, the same as for
external commands, the same as for numeric handles, then:
* the behaviour would be uniform,
* the cognitive burden would be reduced
* and there would be no behaviour dependent on the runtime environment
(export -f to wrap external commands).
* and no risk of unexpected or hard to control fd leaks to subsequent
external (long lived) commands

This would allow users to have full and safe benefit of bash-selected fd's,
which I am sure is what is intended.

I have done my best to be clear in a reasonable manne

Re: leaks fd for internal functions but not external command

[Sam Liddicott]

Thanks for your continued engagement, it is appreciated.

I was focused on my case where I used _ as the name of the file descriptor
because I didn't want to retain it, for I was using named fd as a way to
avoid trampling on an fd already in use, rather than as an open method.

I'm writing up a shellcheck recommendation, to advise others like me on
making sure that the fd is closed. Would be OK to post it here for review,
or would it not be of interest?

Some thoughts since come to mind while writing this:

Perhaps if the named fd is also closed on the same statement that opened
it, it could be kept closed rather than saved and re-opened.
Being closed at the same statement is a strong indicator that it was only
used to aid fd transplants. Why keep open what the author closed?

{tmp_fd}>&2 2>&1 1>&${tmp_fd} {tmp_fd}<&-
  ^^^ not even kept open the the
command it was used for

I also find that: internalize() { "$@" ; }

lets me use the word internalize as a prefix to make external or internal
commands all appear internal. it thus extends the open syntax to even
external (non-pipeline) commands, and permits a uniform clean-up without
risking closing the wrong fd. I wonder if the shell might do this
transparently in the case that a named fd was used (a mere idle wish, pay
it no heed, though it would add uniformity).

Another idea is along the lines wiping the fd variable before the statement
(as we are planning to trample on it) and closing it afterwards only if set

# close fd vars if set, preserve prior exit code
maybe-close( ) {
  set -- $? "$@"
  while test "$#" -ge 2
  do
if test -n "${!2}"
then eval exec "{$2}<&-"
fi
unset "$2"
set -- "$1" "${@:3}"
  done
  return $1
}

tmp_fd= && echo {tmp_fd}>&2 2>&1 1>&${tmp_fd} {tmp_fd}<&- ; maybe-close
tmp_fd

they are my thoughts on avoiding the need to detect the special case of
internal commands in order to close the fd

I appreciate your time and the maintenance of bash and readline.

thanks again

Sam

On Thu, 25 Jul 2019 at 12:52, Chet Ramey  wrote:

> On 7/24/19 9:07 AM, Sam Liddicott wrote:
> > Thanks for that thoughtful response.
> >
> > * I understand that the design decision is to have variable file
> > descriptors to stay open after per-command redirection
>
> Yes.
>
> > * I understand that implementation constraints make it impossible to do
> > this uniformly (for external command redirection)
>
> I'm not sure "implementation constraints" is the right characterization.
> Performing redirections in child processes is how shells work.
>
> > * I understand that it is difficult for the script author to detect which
> > case his code will be
>
> I don't think this is true. The documentation is pretty clear.
>
> > The shell normally does a great job of hiding the difference between
> > internal and external commands, so even though it's very well documented,
> > most of the time the user doesn't need to be aware. This is great for the
> > user, and according to the principle of least surprise.
>
> This isn't quite the case. The shell isn't particularly obscure about
> the fact that printf has to be a builtin for `printf -v' to work, for
> instance.
>
> >
> > The syntactic sugar of having bash select a free fd (which necessary for
> > good composability of operations in complex script pipelines) is a great
> > benefit, especially when mixing with older pipelines having fixed
> numeric fd.
>
> Older shells, you mean. Yes, that was the original motivation for it.
> POSIX makes the limitation implementation-defined, and bash has never had
> it, so it's reasonably easy to choose something that won't collide. But
> it's nice not to have to.
>
> > You say that there are technical reasons why the syntactic sugar of also
> > keeping the fd open can't be implemented uniformly.
>
> Technical reasons in the sense of the relationship between parent and child
> processes, I suppose you mean.
>
> > I wonder if this puts unnecessary cognitive burden on the user, leading
> to
> > reluctance to get the benefits, or to the introduction of latent bugs.
> >
> > There is a case I explain below which can lead to a leaked fd being held
> on
> > to by subsequently invoked external processes. Of course it will
> > technically be the users fault but I'm looking at reducing the cognitive
> > burdens that make such a fault ultimately inevitable.
> >
> > The cognitive burdens of leaving the fd open are:
> >
> > 1. It breaks the normal expectation th

Re: leaks fd for internal functions but not external command

[Sam Liddicott]

This just made me sad:

tedious_function() {
  : # lots of stuff
} {BASH_XTRACEFD}>/dev/null

it would be so cool to be able to disable debug output BASH_XTRACEFD like
that whether or not BASH_XTRACEFD was set.
I guess the variable would have to be local to the function invocation too.

Please add it to the wishlist for bash 5 ;-)


On Thu, 25 Jul 2019 at 15:11, Chet Ramey  wrote:

> On 7/25/19 9:03 AM, Sam Liddicott wrote:
>
> > Perhaps if the named fd is also closed on the same statement that opened
> > it, it could be kept closed rather than saved and re-opened.
> > Being closed at the same statement is a strong indicator that it was only
> > used to aid fd transplants. Why keep open what the author closed?
>
> That's an interesting suggestion. I considered it at some point, and
> there's even a comment in the code about it. I'll look at it again.
>
> Chet
>
> --
> ``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/
>

%q with truncating size loses safeness of %q

[Sam Liddicott]

Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS:  -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu'
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash'
-DSHELL -DHAVE_CONFIG_H   -I.  -I../. -I.././include -I.././lib
-Wdate-time -D_FORTIFY_SOURCE=2 -g -O2
-fdebug-prefix-map=/build/bash-N2nMjo/bash-4.4.18=.
-fstack-protector-strong -Wformat -Werror=format-security -Wall
-Wno-parentheses -Wno-format-security
uname output: Linux sojojojo 5.3.0-46-generic #38~18.04.1-Ubuntu SMP
Tue Mar 31 04:17:56 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu

Bash Version: 4.4
Patch Level: 20
Release Status: release

Also occurs on 5.0.7(1)-release

Description:
printf %q with a truncating size will emit partially escaped
sequence thus losing the safety and composability that %q
is intended to provide.

Repeat-By:
$ printf 'echo %.2q%q\n' "a'b" ';ls'
echo a\\;ls
The semi-colon is no longer escaped, the expectation of
the %q formatter is lost

Fix:
If it the escape sequence that is to be limited in size,
then it should avoid emitting a partial sequence

If the product of the  sequence is to be limited in size, then
the truncating  size quantifer should apply to the input, so
that it will emit output which will produce a value of the
specified length

Re: %q with truncating size loses safeness of %q

[Sam Liddicott]

So is it to be "fixed" in the documentation with a warning that
truncating-size specifiers for %q may nullify the safety benefits for which
it is used?

Sam

On Fri, 17 Apr 2020, 21:12 Chet Ramey,  wrote:

> On 4/17/20 10:22 AM, Sam Liddicott wrote:
>
> > Bash Version: 4.4
> > Patch Level: 20
> > Release Status: release
> >
> > Also occurs on 5.0.7(1)-release
> >
> > Description:
> > printf %q with a truncating size will emit partially escaped
> > sequence thus losing the safety and composability that %q
> > is intended to provide.
> >
> > Repeat-By:
> > $ printf 'echo %.2q%q\n' "a'b" ';ls'
> > echo a\\;ls
> > The semi-colon is no longer escaped, the expectation of
> > the %q formatter is lost
>
> I would say this is a programmer error.  The way precisions work with
> string arguments is that the argument is fetched or generated (this
> includes generating the quoted string for %q or the expanded string for
> %b) and then printf writes number of bytes (!) from that generated string
> specified by the precision.
>
> Chet
>
> --
> ``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: %q with truncating size loses safeness of %q

[Sam Liddicott]

In my case I was using process substitution to generate a dynamic bashrc
file as part of invoking an SDK environment.

Naturally those lines which emit environment variable assignments use %q

I had one build version tracking variable which was to be limited to 7
characters and set to a lowercase form of the username.

The most concise but surprisingly unsafe form is.

printf 'BUILD_VER_SUFFIX=%.7q\n' "${USER,,}"

That's clearly not artificially contrived; (though the user has the ability
to directly mess up their build environment anyway if they so wish).

The answer is obviously "don't do that" but it that requires a special
obscure knowledge which isn't documented.

Can we have bash printf to also not do that? Or if it must break the
security feature got which it exists can at least be documented?

I think I've made myself clear so I went harp on about it anymore unless I
find a more egregious opportunity for abuse.

Sam


On Fri, 17 Apr 2020, 23:38 Robert Elz,  wrote:

> Date:Fri, 17 Apr 2020 16:12:20 -0400
> From:Chet Ramey 
> Message-ID:  <4bacf2f0-9802-67d3-f30b-80e37d058...@case.edu>
>
>   | I would say this is a programmer error.  The way precisions work with
>   | string arguments is that the argument is fetched or generated (this
>   | includes generating the quoted string for %q or the expanded string for
>   | %b) and then printf writes number of bytes (!) from that generated
> string
>   | specified by the precision.
>
> This happens only because of the cheap way we (and I presume you)
> implement things - in any rational scheme, it would take the precision
> chars from the source string, and then quote them.
>
> But that's hard - instead we just use printf to do the work, %q quotes
> the arg string, and then the 'q' is changed to a 's' in the format, and
> we just call printf(3) to do the work (padding, justification, ...)
>
> The only excuse for this is pragmatics, no-one would deliberately set
> out to design something quite that bogus.
>
> The end result is as Greg said, "Don't do that", if precisions are
> needed with %q do something like
>
> printf 'echo %q%q\n' "$(printf %.2s "a'b")" ';ls'
>
> which produces
>
> echo a\'\;ls
>
> which I expect is the desired result.
>
> kre
>
>

Re: %q with truncating size loses safeness of %q

[Sam Liddicott]

On Sun, 19 Apr 2020 at 20:40, Chet Ramey  wrote:
>
> On 4/17/20 6:37 PM, Robert Elz wrote:
>
> > This happens only because of the cheap way we (and I presume you)
> > implement things - in any rational scheme, it would take the precision
> > chars from the source string, and then quote them.

That, or at least refuse to emit a dangling escape char. There are
arguments against both.
GNU Coreutils printf rejects size specifiers for %q and %b, probably
for this reason.

> Nobody, including POSIX, is rational, then.

Chet, I don't know that POSIX attempt to make a guarantee about output
being reusable as shell input at all, so I don't know that we need to
fallback on POSIX as a reason to break that guarantee.

I that although GNU coreutils printf doesn't exhibit this behaviour of
%q (entirely rejecting size specifiers for it) ksh does exhibit this
behaviour, I will make a report there.

This is another candidate for shellcheck I guess, which reminds me
that I forgot to submit the one for leaky named file descriptors (in
contrast to numeric ones).

Sam

Bash wrongly attaches subcommand stdin on syntax error

[Sam Liddicott]

Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS:  -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu'
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL
-DHAVE_CONFIG_H   -I.  -I../. -I.././include -I.././lib
-D_FORTIFY_SOURCE=2 -g -O2 -fstack-protector --param=ssp-buffer-size=4
-Wformat -Werror=format-security -Wall
uname output: Linux sojojojo 3.13.0-37-generic #64-Ubuntu SMP Mon Sep 22
21:28:38 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu

Bash Version: 4.3
Patch Level: 11
Release Status: release

Description:
Shell wrongly attaches stdin piped to command sequence with syntax error

Repeat-By:
On a login shell or interactive shell, paste the following command:

for x in 1 ; do echo $( { echo } ) ; done < <( echo touch /tmp/x2 )

The handling of the syntax error will cause stdin of the command
to become attached to the login shell, which will then execute:
  touch /tmp/x2
and then logout.

This bogus behaviour does not occur if the for-loop is dropped from
the example.

This script demonstrates the problem in a shell script, where stdin
of the entire script is diverted, though not necessarily the
commands to be executed

#! /bin/bash
set -x
for x in 1 ; do echo $( { echo } ) ; done < <( echo touch /tmp/x2 )
cat

The text "touch /tmp/x2" is emitted to stdout

As this depends on a syntax error I haven't worked out how it might
be exploited as a security hole

time builtin does not work with set -e when a command fails

[Sam Watkins]

Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS:  -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' 
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu' 
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL 
-DHAVE_CONFIG_H   -I.  -I../bash -I../bash/include -I../bash/lib  
-D_FORTIFY_SOURCE=2 -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat 
-Werror=format-security -Wall
uname output: Linux opal.nipl.net 3.2.0-4-amd64 #1 SMP Debian 3.2.65-1+deb7u2 
x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu

Bash Version: 4.2
Patch Level: 37
Release Status: release

Description:
The time builtin does not work with set -e when a command fails.
The "time" builtin should give timing for a command regardless of exit 
status.

Examples:

# 1. with set -e, the time builtin is silent for failed commands (this 
is the bug)
$ bash -ce 'time false'

# 2. normally the time builtin gives times for failed commands
$ bash -c 'time false'

real0m0.000s
user0m0.000s
sys 0m0.000s

# 3. the time(1) utility gives times for failed commands with set -e, 
of course
$ bash -ce 'command time false'
Command exited with non-zero status 1
0.00user 0.00system 0:00.00elapsed 0%CPU (0avgtext+0avgdata 
1664maxresident)k
0inputs+0outputs (0major+150minor)pagefaults 0swaps

Repeat-By:
$ bash -ce 'time false'

Re: printf fails in version 5.2.026-3

[Sam James]

szige...@delg0.elte.hu writes:

> Configuration Information [Automatically generated, do not change]:
> Machine: x86_64
> OS: linux-gnu
> Compiler: gcc
> Compilation CFLAGS: -march=x86-64 -mtune=generic -O2 -pipe -fno-plt
> -fexceptions -Wp,-D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security
> -fstack-clash-protection -fcf-protection -g
> -ffile-prefix-map=/build/bash/src=/usr/src/debug/bash -flto=auto
> -DDEFAULT_PATH_VALUE='/usr/local/sbin:/usr/local/bin:/usr/bin'
> -DSTANDARD_UTILS_PATH='/usr/bin' -DSYS_BASHRC='/etc/bash.bashrc'
> -DSYS_BASH_LOGOUT='/etc/bash.bash_logout'
> -DNON_INTERACTIVE_LOGIN_SHELLS
> uname output: Linux delg0 6.6.36-1-lts #1 SMP PREEMPT_DYNAMIC Thu, 27 Jun 
> 2024 12:26:27 + x86_64 GNU/Linux
> Machine Type: x86_64-pc-linux-gnu
>
> Bash Version: 5.2
> Patch Level: 26
> Release Status: release
>
> Description:
>   printf works in version 5.2.026-2, fails in version 5.2.026-3
>
> Repeat-By:
>   contents of tmp.sh begins 
>   #!/usr/bin/env bash
>   a=1
>   printf "%.2f\n" "$a"
>   contents of tmp.sh ends --
>
>   5.2.026-2> ./tmp.sh
>   1.00
>
>   5.2.026-3> ./tmp.hs
>   nan
>
> Fix:
>   I don't understand what is happening, my current fix is downgrading to 
> 5.2.026-2.

I suspect, based on your environment, that you're using Arch Linux or a
derivative. See
https://gitlab.archlinux.org/archlinux/packaging/packages/bash/-/issues/3.

Re: printf fails in version 5.2.026-3

[Sam James]

Daniel Lublin  writes:

> Apparently the patch needed to fix this was the one Florian Weimer
> posted in november 2023, in "C compatibility issue in the configure
> script" <8734oqnlou@gentoo.org> (if you don't have the mail history:
> https://lists.gnu.org/archive/html/bug-bash/2023-11/msg00104.html)
>
> Maybe some compiler change triggered this now.

Yes, GCC 14 makes various things stricter - for the better - and this
can affect configure scripts.

Arch didn't, as far as I know, do a mass-rebuild when adding GCC 14,
which means these issues now only show up when a package gets updated
for unrelated reasons. I consider this to not have been the ideal
strategy. We did try to advertise what people should do, but you can
only shout so much.

Re: Support ksh93 x=${cmd;}

[Sam James]

Cedric Blancher  writes:

> Good morning!
>
> Could bash please support x=${cmd;} alongside x=$(cmd)?
>
> x=$(cmd;} works like x=$(cmd), except that cmd does not run in
> a subshell, i.e. the stdout within ${cmd;} is redirected to the
> variable "x", but any other changes of variables (global/static/local)
> are also available outside ${}, unlike $()
>
>  can be anything of blank, tab, newline. The cmd must ALWAYS be
> terminated with a ";".
>
> Example:
> ksh93 -c 'out_stderr="${ { out_stdout="${ ls x ; (( out_res=$? )) ; }"
> ; } 2>&1 ; }" ; printf "stdout=%q, stderr=%q, exit code=%d\n"
> "$out_stdout" "$out_stderr" "$out_res"'
> stdout='', stderr=$'ls: cannot access \'x\': No such file or
> directory', exit code=2

See https://lists.gnu.org/archive/html/bug-bash/2025-04/msg00023.html.

bash-4-2 issue

[Sam Kappen via Bug reports for the GNU Bourne Again SHell]

Hi,

We see that bash throws the "Operation not permitted" error when doing
chained pipe operation
along with a debug trap.

We set a debug trap here "my_debug" to save the terminal commands entered.
The GNU bash, version used is  4.2.

root@freescale-p2020ds:~/dir#  ls -l | grep a | grep b | grep c
-sh: child setpgid (4238 to 4232): Operation not permitted


root@freescale-p2020ds:~/dir# trap
trap -- '' TSTP
trap -- '' TTIN
trap -- '' TTOU
trap -- 'my_debug' DEBUG
root@freescale-p2020ds:~/dir#

Platform: Linux 3.10 kernel on PPC target.

It seems setpgid is failing because the process group of the pipeline does
not exist at that time.

This issue is not seen on bash version 4.4. The commit (
https://git.savannah.gnu.org/cgit/bash.git/commit/?h=bash-4.4&id=a0c0a00fc419b7bc08202a79134fcd5bc0427071)
seems
to have fixed it.

I am looking to figure out the particular fix that fixed this issue from
the above commit and to backport to bash4-2 version.

Is it a known  issue? Could you help to identify the change set  that fixed
the issue from the commit "a0c0a00fc419b"?
Thanks in advance.

Regards,
Sam

Re: bash-4-2 issue

[Sam Kappen via Bug reports for the GNU Bourne Again SHell]

On Thu, Jan 11, 2024 at 1:03 AM Grisha Levit  wrote:

> On Wed, Jan 10, 2024 at 5:33 PM Grisha Levit 
> wrote:
> > I'm not sure this is fixed. In all versions, including 4.2 [...]
> >
> > $ bash -m -c 'trap /usr/bin/true DEBUG; :|:'
> > bash: child setpgid (49581 to 49579): Operation not permitted
>
> Correction, versions prior to 4.3 did not respect the -m flag at
> invocation,
> so the command should be:
>
> bash -c 'set -m; trap /usr/bin/true DEBUG; :|:'
>

Thanks.
I am using a Linux host with kernel version 4.x for cross building.
It looks like autoconf is not defining the "PGRP_PIPE" macro variable as
there is no check for linux kernel version 4.
I don't see the error " child setpgid (4238 to 4232): Operation not
permitted" after I backport this patch
https://git.savannah.gnu.org/cgit/bash.git/diff/configure.ac?h=bash-4.4-testing&id=3bf257a5d95aa7d98d3da1a24be7b5b301716047
to bash-4.2