From 29e0bd45dd449cf67787d23ea482b54ddb435690 Mon Sep 17 00:00:00 2001
From: "Mark T. Kennedy"
Date: Fri, 11 Apr 2025 19:22:05 -0400
Subject: [PATCH] Update mtk's email addresses
Signed-off-by: Mark T. Kennedy
---
examples/functions/autoload.v3 | 4 ++--
1 file changed, 2 i
$'foo\nbar' | tee >(echo first ; exit 1) >(wc ; sleep 10 ; echo wc) >(tail
-n 1; echo tail)wait
blocks for 10s under Bash 5.2.21.
Likely just a documentation bug.
-Mark
On Saturday, June 29, 2024 at 07:52:34 PM PDT, Zachary Santer
wrote:
On Sat, Jun 29, 2024 at 2:07 P
Thank you for a quick fix. Bash 5.2.21 with the patch applied no longer
exhibits the problem in my tests.
-Mark
On Thursday, June 27, 2024 at 06:05:28 AM PDT, Chet Ramey
wrote:
On 6/18/24 4:55 PM, Mark March wrote:
> I am working with a large Bash code base where most scripts disa
e any work-arounds
other than not using the DEBUG trap or leaving job control on?
-Mark
On Tuesday, June 18, 2024 at 02:48:51 PM PDT, Mark March
wrote:
I am working with a large Bash code base where most scripts disable job
control and the DEBUG trap is used extensively. I noticed th
ts, although I was not able to confirm
this with strace.
In my repro pipeline_pgrp is non-zero at the time of DEBUG trap execution. gdb
shows that it was set to shell_pgrp in make_child() that forked /bin/echo
without job control (+m). The other condition of the if statement is also
satisfied.
-Mark
like the HISTTIMEFORMAT activates the HISTTIME
Mark
in why it's
more detailed there and not for -C. It is curious that they're so different.
Cheers,
Mark C.
On 07/07/2022 00:11, Chet Ramey wrote:
On 7/4/22 12:03 AM, Mark Chandler via Bug reports for the GNU Bourne Again
SHell wrote:
Configuration Information [Automatically genera
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -O2 -flto=auto -ffat-lto-objects -fexceptions -g
-grecord-gcc-switches -pipe -Wall -Werror=format-security
-Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS
-specs
cently in
https://lists.gnu.org/archive/html/bug-bash/2020-08/msg00206.html. I use
namerefs extensively in a fairly large Bash code base for parameter passing,
and I have to use fairly elaborate work-arounds to detect local variables
shadowing outer-scope variables that the function operates on via namerefs.
-Mark
in particular, a file descriptor is also ready on end-of-file)."
-Mark
amp;& { set +u; ... set -u; } around my [[ ${foo@a} =~ A ]] for now.
Thanks again for your explanation and context.
-Mark
On Tuesday, October 26, 2021, 07:02:59 AM PDT, Chet Ramey
wrote:
On 10/25/21 8:24 PM, Mark March wrote:
> If -u is on and you declare a simple or associative array
of the fix that you described in item (n) of
the most recent change log:
n. Fixed a bug that caused ${foo@a} to treat foo as an unset variable if it was
an array without a value for subscript 0/"0" but had other set elements
Thanks,
-Mark
her hand, not doing this will lead to subtle bugs where cleanup code will
suddenly not run, or processes unexpectedly catch signals that have been
previously blocked.
-Mark
On Friday, October 8, 2021, 08:02:31 AM PDT, Chet Ramey
wrote:
On 10/1/21 2:16 PM, Mark March wrote:
> Ok, thank yo
Ok, thank you for clarifying. There is nothing in the documentation about this
behavior as far as I can tell. I would suggest adding a line about traps
getting reset after a failed exec to the paragraph on 'execfail'.
-Mark
On Friday, October 1, 2021, 07:02:34 AM PDT, Chet Ram
tin command. An interactive shell does not
exit if exec fails.
It says nothing about the traps getting reset. In my example the script clearly
continues to execute after the failed exec, as it should (since execfail is
set).
-Mark
On Thursday, September 30, 2021, 04:47
Output:
bash: line 3: /home/march/does-not-exist: No such file or directory
exec failed in bash-5.0.17(1)-release
The "exiting..." line is missing. If you comment out exec ~/does-not-exist,
"exiting..." will be printed as expected.
I get this under 5.1.8 as well, built with gcc 9.3 This is on Ubuntu 20 on
x86_64.
-Mark
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-unknown-linux-gnu'
-DCONF_VENDOR='unknown' -DLOCALEDIR='/usr/local/share/l
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS:A -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu'
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/s
should take steps to ensure
y.tab.c is actually generated.
For everyone else surely it should be their responsibility to have the
required tools available at build time?
Thanks,
Mark.
Greetings,
On 28 Sep 2014 19:41, "John E. Malmberg" wrote:
>
> On 9/27/2014 6:49 PM, Mark Goldfinch wrote:
>> 1) Remove y.tab.c from the original tarball, and ensure the clean method
>> within Makefile removes it
>
> The VMS build procedure currently needs the y
will result, at
worst a bash build which is thought to address problems, won't.
Thoughts?
Thanks,
Mark.
n for `x'
this is a test
bash-4.3# (X='() { (a)=>\' bash -c "echo ls /etc; cat echo")
bash: X: line 1: syntax error near unexpected token `='
bash: X: line 1: `'
bash: error importing function definition for `X'
ls /etc
cat: cannot open echo
I've ju
Ah great, thanks for that...though since there's still the bug in p025 (see
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-7169 ) I'll keep
spinning my wheels and watching the git branches until p026 rolls out.
ta,
Mark
On Thu, Sep 25, 2014 at 3:55 PM, Chris F.A. Johnson
wr
>Bash-Release:4.3
>Patch-ID:bash43-025
As a binary distribution archive maintainer, I'd be keen to see the authors
distributing a cumulative bash-4.3p025.tar.gz source bundle (probably p026 to
nail the new issues above). The ftp://ftp.cwru.edu/pub/bash site just has the
main 4.
On Mon, May 19, 2014 at 10:45 AM, Greg Wooledge wrote:
> On Mon, May 19, 2014 at 10:39:59AM -0700, Mark Ferrell wrote:
>> I'm sorry, but the lack of consistency still sounds like it is a bug
>> in bash. The behaviour I would expect is functionally equivalent to
>>
/dev/null 2>&1 || err_handler
set -e
exit_handler() { echo "exit code: $?"; }
main()
{(
trap exit_handler 0
/bin/false >> /dev/null 2>&1
)}
main "$@"
On Mon, May 19, 2014 at 7:00 AM, Chet Ramey wrote:
> On 5/18/14, 12:56 PM, Mark Ferrell wrote:
&
e exit handler is called, you just muted it. remove the redirections, and
> you'll also notice you need a space after your !
>
>
> On 16 May 2014 12:41, Mark Ferrell wrote:
>>
>> The following script properly reports the exit code to the calling
>> environment, , b
The following script properly reports the exit code to the calling
environment, , but the exit handler is not called if a function
triggers the exit vs an external command.
Script executed via:
bash
that I was
having a name collision problem. I changed my function _cd to __cd, and now
tab completion works as it did before. Seems _cd is being defined in
/etc/bash_completion so my _cd was trashing this function and causing
auto-complete weirdness.
Mark
-Original Message-
From:
blem.
If I set the alias but then unset -f _cd, I get:
cd bash: completion: function `_cd' not found
So it's as if once the alias is set, tab completion always follows the alias
even after I unset it.
Mark
-Original Message-
From: Linda Walsh [mailto:b...@tlinx.o
From: mwjohnso
To: bug-bash@gnu.org
Subject: cd completion using aliased cd command
Configuration Information [Automatically generated, do not change]:
Machine: i686
OS: cygwin
Compiler: gcc-4
Compilation CFLAGS: -DPROGRAM='bash.exe' -DCONF_HOSTTYPE='i686'
-DCONF_OSTYPE='cygwin' -DCONF_MACHTYPE=
I'm willing to bet there is plenty of code out there that tries to decide
whether it is safe to create a file and would fall foul of an errant dead
symbolic link.
A little off topic but are -a and -e identical?
Cheers,
mark
tance creating a symbolic link:-
E.g.
$ ln -s c a
$ ls -l a b c
ls: b: No such file or directory
ls: c: No such file or directory
lrwxrwxrwx 1 marky tools 1 Jun 21 14:41 a -> b
Is this an error in bash?
What test should I use to decide if a file exists (including dead symbolic
links)?
Cheers,
Mark
ifests on BASH_VERSION="4.1.5(1)-release" and
the latest Bash release BASH_VERSION="4.2.0(1)-release", but not
on BASH_VERSION="3.2.48(1)-release".
-Mark
x86_64-pc-linux-gnu
Bash Version: 4.0
Patch Level: 33
Release Status: release
Description:
`help test' output is missing `==' string equality operator.
Repeat-By:
$ help test
Fix:
Push the attached patch?
From 4328a3719f591011f5ffab0577e325f5e582e539 Mo
OK,
Thank You, VML.
Chet Ramey wrote:
V. Mark Lehky wrote:
Hi,
I can't find this text in my manual. Is there a more recent version
somewhere than <http://www.gnu.org/software/bash/manual/bashref.html>?
Sure. The 2.05b manual is over four years old. Try
http://cnswww.cns.cwr
o the same thing? Or did I interpret that wrong?
Thanx, VML.
Chet Ramey wrote:
V. Mark Lehky wrote:
Hi,
This is in reference to "Edition 2.5b, last updated 15 July 2002, of The
GNU Bash Reference Manual".
Please, please, please, for the sake of future generations, make the
followin
Hi,
This is in reference to "Edition 2.5b, last updated 15 July 2002, of The GNU
Bash Reference Manual".
Please, please, please, for the sake of future generations, make the following
addition in two spots in the next release of the manual. I just spent like three
hours hunting this down:
found
If I changed the recommended make statement to:
make STATIC_LD= LOCAL_LIBS='-B dynamic -R/usr/lib -lnsl -ldl -B static'.
It works on both Sol 9 and Sol 10 now.
Cheers,
Mark
Chet Ramey wrote:
> Mark Reis wrote:
>
>> I'm attempting to build a static versio
shared .so libraries
under INTL_LIB and LIBINTL . It was a simple fix to switch them to ".a".
Thanks for the help
-Mark
Chet Ramey wrote:
> Well, the compiler's not finding , that much is clear.
>
> Chet
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
I'm attempting to build a static version of Bash 3.1 on Solaris 9 using
Sun's cc version
5.8 2005/10/13. It fails during make when compiling
(I'm attempting to install to the /usr/cs directory). Any help would
be appreciated.
make STATIC_LD= LOCAL_LIBS='-B dynamic -ldl -B static'
*
n" 1'
1
I would expect:
% /bin/bash --version
GNU bash, version 3.00.16(1)-release (sparc-sun-solaris2.10)
Copyright (C) 2004 Free Software Foundation, Inc.
% /bin/bash -c 'printf "%0.5d\n" 1'
00001
Any ideas, anyone?
cheers
mark
--
Mark Robinson
Consultant
Vi
login. Yes, I now you can specify an alternate bashrc with the --rcfile
parameter, but then subsequent instances of bash invoked by screen, for
instance, do not know about the alternate location of bashrc.
cheers
mark
---8
Title: Out of Office AutoReply: Auf Streife durch den Berliner Wedding
I will be out of the office traveling on Thursday and Friday but will monitor my email. If you have any questions, please contact my assistant Maggie Hegarty at 612-492-6019.
_
http://www.rocknord.de
http://www.aktivefrauenfraktion.tk
http://www.kopfmord.de
http://www.das-gibts-doch-nicht.de
http://www.zukunft-europa.info/index.html
http://www.geocities.com/scorpios2602/links.html
http://www.g-d-f.de
http://www.bewaeltigen.de
http://www.wk-institut.de
http://www.jungefrei
45 matches
Mail list logo
