Re: SLA Information
This has come to the bash-bug volunteers mailing list. Many of us, myself included, offer software consulting services, and would happily provide the support you seek, but it would be helpful if you could clarify the type of support that you're looking for: (a) bug fixes for bash itself, or (b) support for your developers writing bash scripts. That said, Bash has been effectively tested in the real world for over 30 years, so the practical value of paying for category (a) support is questionable: it's faster and cheaper just to adjust your scripts to work around any bugs, and fixes to bugs bring a risk of inducing failures elsewhere. In my experience bugs in Bash scripts outnumber bugs in Bash by at least 1000 to 1, and likely much higher, as the *majority* of scripts visible on the internet have latent bugs detectable through automated analysis, and sampling indicates that most of the rest also have bugs. Only a small fraction are robustly written. Most claims about Bash turn out to be bugs in the scripts, and even in those that correctly identify the behaviour of Bash, at least half are where Bash is behaving *correctly*, in accord with the POSIX standard for the Shell language. Sadly most script writers have not even read Bash's own documentation, much less read and understood the POSIX standard. -Martin On Sat, 19 Aug 2023, 04:27 Malena Arduino via Bug reports for the GNU Bourne Again SHell, wrote: > To whom it may concern, > > I am working on creating an SLA for my company and was hoping to gain some > clarity on your support for GNU Bash. If you could please provide me > insight on the following items: > > - Support Type (what type of support is offered? General? Sales? > Technical?) > - Contact Format (how should someone contact [name]? Phone? Live Chat? > Email?) > - Hours of Operation (what days and hours do you provide support? EX: > 8:00-16:00 (PDT/PST)) > - Response Time (for each contact format, what is the expected response > time) > - Support Engagement (who is authorized to contact support? or who has > access to support?) > > I am creating a table with this information. Below I showcase an example: > > | Vendor Name | Contact Page | Support Type | Contact Format | Contact | > Availability | Response Time | Support Engagement | > > I look forward to your response. Thank you in advance. > > Best, > Malena >
SLA Information
To whom it may concern, I am working on creating an SLA for my company and was hoping to gain some clarity on your support for GNU Bash. If you could please provide me insight on the following items: - Support Type (what type of support is offered? General? Sales? Technical?) - Contact Format (how should someone contact [name]? Phone? Live Chat? Email?) - Hours of Operation (what days and hours do you provide support? EX: 8:00-16:00 (PDT/PST)) - Response Time (for each contact format, what is the expected response time) - Support Engagement (who is authorized to contact support? or who has access to support?) I am creating a table with this information. Below I showcase an example: | Vendor Name | Contact Page | Support Type | Contact Format | Contact | Availability | Response Time | Support Engagement | I look forward to your response. Thank you in advance. Best, Malena
pathological bash-malloc behaviour
Hi bash developers!
I think I encountered an unusual pathological behaviour of `bash-malloc`.
I have a directory with ~500_000 files and directories in it. I tried
to iterate through it with a single `for` loop using `*` glob and
noticed that glob expansion takes more time that actual loop payload
(the payload is to match and print a few names).
The reproducer (best ran on `tmpfs`):
# prepare test directory with ~900_000 files of different name
# lengths:
$ mkdir dd; for i in {1..10}; do echo
dd/$i.{,1,22,333,,5,66,777,,99}; done | xargs
touch
Make sure you have started a new interactive shell after directory
creation.
# trigger bug:
$ time { echo ./* > /dev/null; }
real7m9,378s
user7m8,327s
sys 0m0,277s
# second run is faster
$ time { echo ./* > /dev/null; }
real0m1,915s
user0m1,723s
sys 0m0,190s
# until we do a minor change:
$ time { echo .//* > /dev/null; }
real0m34,689s
user0m34,470s
sys 0m0,199s
# second run is faster again:
$ time { echo .///* > /dev/null; }
real1m6,269s
user1m5,999s
sys 0m0,195s
# and so on:
$ time { echo .///* > /dev/null; }
real1m6,269s
user1m5,999s
sys 0m0,195s
$ time { echo .///* > /dev/null; }
real0m2,420s
user0m2,212s
sys 0m0,206s
Note that initial expansion always takes 100x of the time we do it
the second time. This happens on `x86_64-linux` system with `bash`
configured as `./configure`. I suspect it has to do with the total
amount of memory allocated (and freed) by `bash` by the time the test
is ran.
If I `./configure` `bash` as `--without-bash-malloc` I see faster
behaviour on `glibc` system:
$ time { echo * > /dev/null; }
real0m0,969s
user0m0,737s
sys 0m0,231s
$ time { echo ./* > /dev/null; }
real0m1,296s
user0m1,097s
sys 0m0,198s
$ time { echo .//* > /dev/null; }
real0m1,380s
user0m1,183s
sys 0m0,196s
$ time { echo .///* > /dev/null; }
real0m1,408s
user0m1,225s
sys 0m0,181s
$ time { echo .* > /dev/null; }
real0m2,520s
user0m2,309s
sys 0m0,203s
The performance analysis points at `internal_malloc()` as the main CPU
user:
$ perf top -p $pid
99,54% bash [.] internal_malloc.constprop.0
0,03% [kernel] [k] read_tsc
0,03% [kernel] [k] __update_load_avg_se
...
`INSTALL` file says that `--with-bash-malloc` is enabled by default and
hints that it's possibly a faster allocator that default system's one.
Should the allocator be tweaked to handle this pathological behaviour?
Or maybe it's a good time for `linux` target to switch to
`--without-bash-malloc` as a faster default?
Thanks!
--
Sergei
[REGRESSION] Incorrect libcurses detection in 5.2.15 (on HP-UX)
Folks, while trying to configure and compile 5.2.15 on HP-UX it does not properly detect libcuses and fails to detect installed libreadline. The regression is identical to the one I reported with readline: https://lists.gnu.org/archive/html/bug-readline/2023-08/msg9.html Here is a simple patch which works for me: diff -ur configure configure --- configure 2023-08-17 21:17:53 +0200 +++ configure 2023-08-17 21:23:41 +0200 @@ -5960,8 +5960,7 @@ TERMCAP_LIB= TERMCAP_DEP= else -# we assume ncurses is installed somewhere the linker can find it -TERMCAP_LIB=-lncurses +TERMCAP_LIB=-lcurses TERMCAP_DEP= fi @@ -21584,8 +21583,7 @@ TERMCAP_LIB= TERMCAP_DEP= else -# we assume ncurses is installed somewhere the linker can find it -TERMCAP_LIB=-lncurses +TERMCAP_LIB=-lcurses TERMCAP_DEP= fi So the source in aclocal.m4 needs to be fixed. Result: # ldd /opt/ports/bin/bash /opt/ports/bin/bash: libreadline.so.8 => /opt/ports/lib/hpux32/libreadline.so.8 libhistory.so.8 => /opt/ports/lib/hpux32/libhistory.so.8 libxcurses.so.1 => /usr/lib/hpux32/libxcurses.so.1 libintl.so.11 =>/opt/ports/lib/hpux32/libintl.so.11 libiconv.so.8 =>/opt/ports/lib/hpux32/libiconv.so.8 libdl.so.1 => /usr/lib/hpux32/libdl.so.1 libc.so.1 =>/usr/lib/hpux32/libc.so.1 libc.so.1 =>/usr/lib/hpux32/libc.so.1 libdl.so.1 => /usr/lib/hpux32/libdl.so.1 Note that libcurses links to libxcurses. Michael
