Re: extdebug now implies errtrace which implies `trap ... ERR` execution w/out `set -e`

On 09 Feb 2021 16:40, Chet Ramey wrote: > On 2/9/21 11:51 AM, Mike Frysinger wrote: > > On 09 Feb 2021 11:12, Chet Ramey wrote: > >> On 2/8/21 11:54 PM, Mike Frysinger wrote: > >>> this set of changes between bash-4.3 & bash-4.4: > >>> https:

Re: extdebug now implies errtrace which implies `trap ... ERR` execution w/out `set -e`

On 09 Feb 2021 11:12, Chet Ramey wrote: > On 2/8/21 11:54 PM, Mike Frysinger wrote: > > this set of changes between bash-4.3 & bash-4.4: > > https://git.savannah.gnu.org/cgit/bash.git/commit/?h=814e1ff513ceca5d535b92f6c8dd9af7554fe83e > > I'm glad you're upgrading

extdebug now implies errtrace which implies `trap ... ERR` execution w/out `set -e`

this set of changes between bash-4.3 & bash-4.4: https://git.savannah.gnu.org/cgit/bash.git/commit/?h=814e1ff513ceca5d535b92f6c8dd9af7554fe83e has this buried nugget: + - shopt_set_debug_mode: make sure error_trace_mode reflects the setting + of extdebug. This one is tentative.

Re: add generated files to .gitignore

On 05 Mar 2018 14:33, Chet Ramey wrote: > On 3/5/18 1:15 PM, Mike Frysinger wrote: > > On 02 Mar 2018 14:25, Chet Ramey wrote: > >> On 2/27/18 11:46 AM, don fong wrote: > >>> Chet, thanks for the suggestion. > >>> > >>> i still wonder what's t

Re: add generated files to .gitignore

On 02 Mar 2018 14:25, Chet Ramey wrote: > On 2/27/18 11:46 AM, don fong wrote: > > Chet, thanks for the suggestion. > > > > i still wonder what's the objection to changing .gitignore? > > I don't think it will be useful to me, since I curate the commits I > make to the various branches, but I

Re: Another little patch I would like to put upstream

On 07 Dec 2016 19:09, Chet Ramey wrote: > On 12/5/16 11:01 PM, Mike Frysinger wrote: > > using ^ as an anchor doesn't seem that much better than % > > Ultimately, autoconf is the right way to do this. sure, you could add bashbug to AC_OUTPUT and adapt all the vars to be AC_S

Re: Another little patch I would like to put upstream

On 04 Dec 2016 22:53, Vladimir Marek wrote: > Studio compiler may use things like '-xregs=no%frameptr' for example. > > Thank you > -- > Vlad > # Our compiler flags contain percent sign which get mixed up with percent sign > # seprators used by sed. > > # Submitted to bug-bash@gnu.org >

Re: popd controlled free (Segmentation fault) with bash 4.2.47, 4.3.48, and 4.4.5

On 21 Nov 2016 10:13, Chet Ramey wrote: > On 11/21/16 6:47 AM, wer...@suse.de wrote: > > Bash Version: 4.2.47, 4.3.48, 4.4.5 > > Release Status: release > > OpenSUSE bug: 1010845 > > CVE: 2016-9401 > > > > Description: > > popd controlled free (Segmentation fault) in all bash versions here >

Re: [PATCH 5/5] evalstring: drop volatile on sigset

On 11 Aug 2016 11:45, Chet Ramey wrote: > On 8/11/16 8:30 AM, Mike Frysinger wrote: > > These variables are located on the stack and are never read/written > > directly by bash. Instead, they're all accessed indirectly via the > > POSIX signal API. Since POSIX does not requi

Re: segfault w/bash-4.4-beta2 and assigning empty $*

On 11 Aug 2016 08:32, Chet Ramey wrote: > On 8/11/16 8:29 AM, Mike Frysinger wrote: > > simple code to reproduce: > > bash -c 'v=$*' > > http://lists.gnu.org/archive/html/bug-bash/2016-07/msg00066.html thanks ... still catching up after vacation and hadn't made it

[PATCH 1/5] eaccess: constify path arguments

Noticed when looking into segfault. The "discarding const qualifier" warning always makes me worried as it tends to come from bad code. --- externs.h| 2 +- lib/glob/glob.c | 2 +- lib/sh/eaccess.c | 10 +- 3 files changed, 7 insertions(+), 7 deletions(-) diff --git

[PATCH 4/5] tmpfile: fix pointer cast warning

On systems where sizeof(void*) != sizeof(unsigned int) (e.g. on most 64-bit platforms), we get a warning like so: tmpfile.c: In function 'sh_seedrand': tmpfile.c:128:61: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] srandom (tv.tv_sec ^ tv.tv_usec ^

[PATCH 2/5] general: constify name/file funcs

Noticed when looking into segfault. The "discarding const qualifier" warning always makes me worried as it tends to come from bad code. --- general.c | 26 +- general.h | 18 +- 2 files changed, 22 insertions(+), 22 deletions(-) diff --git a/general.c

[PATCH 3/5] arrayfunc: constify array names

Noticed when looking into segfault. The "discarding const qualifier" warning always makes me worried as it tends to come from bad code. --- arrayfunc.c | 18 ++ arrayfunc.h | 12 ++-- 2 files changed, 16 insertions(+), 14 deletions(-) diff --git a/arrayfunc.c

[PATCH 5/5] evalstring: drop volatile on sigset

These variables are located on the stack and are never read/written directly by bash. Instead, they're all accessed indirectly via the POSIX signal API. Since POSIX does not require volatile, and bash itself doesn't require volatile, drop the volatile markings. If we don't, you get a lot of

segfault w/bash-4.4-beta2 and assigning empty $*

simple code to reproduce: bash -c 'v=$*' gdb backtrace: Program received signal SIGSEGV, Segmentation fault. quote_string (string=0x0) at subst.c:3940 3940 if (*string == 0) #0 quote_string (string=0x0) at subst.c:3940 #1 0x0045c052 in param_expand

Re: Bash-4.4-beta2 available for download

On 12 Jul 2016 21:38, Chet Ramey wrote: > +== CHANGES ==+ > This document details the changes between this version, bash-4.4-beta2, and > the previous version, bash-4.4-rc1. why back to beta ? generally "rc" is considered newer than "beta", and the previous bash-4.4 releases were

Re: avoid mktemp/mkstemp internally

On 19 May 2016 14:37, Chet Ramey wrote: > On 5/16/16 10:36 AM, Mike Frysinger wrote: > >> Because many traditional implementations of mktemp/mkstemp suck. > > > > and many modern implementations work perfectly fine. why is the default > > to penalize good/fixed

Re: avoid mktemp/mkstemp internally

On 16 May 2016 10:02, Chet Ramey wrote: > On 5/13/16 2:40 PM, Mike Frysinger wrote: > > i was pointed at a bug report for FreeBSD systems [1] where running lots > > of processes in parallel would randomly fail with errors like: > > cannot make pipe for process subs

Re: Cannot clone from anonymous git

On 13 May 2016 15:42, Eduardo A. Bustamante López wrote: > http://savannah.gnu.org/git/?group=bash lists: > > | Getting a Copy of the Git Repository > | > | Anonymous clone: > | > | git clone git://git.savannah.gnu.org/bash.git > | > | Member clone: > | > | git clone

avoid mktemp/mkstemp internally

i was pointed at a bug report for FreeBSD systems [1] where running lots of processes in parallel would randomly fail with errors like: cannot make pipe for process substitution: File exists upstream FreeBSD addressed this by defining USE_MKTEMP [2] & USE_MKSTEMP [3] when building bash.

Re: Avoid asterisk expansion when it selects "everything"

On 14 Apr 2016 09:23, Andreas Schwab wrote: > Mike Frysinger <vap...@gentoo.org> writes: > > alternative idea: alias your rm/mv/etc... commands if you're worried > > about them. it's not uncommon to do in ~/.bashrc or wherever: > > alias rm='rm -i' > > Tha

Re: Avoid asterisk expansion when it selects "everything"

On 13 Apr 2016 11:23, Anis ELLEUCH wrote: > I would like to ask if it is possible to disable expanding asterisk when it > selects all entries ? > > `$ rm * .jpg` with a mistaken space between asterisk and .jpg will delete > everything in your home directory or in the entire disk. > > In my

[patch] fix misc warnings

the fixes below cover specific warnings. but there's more i wasn't able to fix. seems like this should be easy ... but iirc i've reported it before ... expr.c:210:17: warning: conflicting types for built-in function ‘exp2’ static intmax_t exp2 __P((void)); there's some weirdness with the

Re: How to lock a terminal

On 16 Feb 2016 18:19, Bob Proulx wrote: > Nick Warne wrote: > > I was in a SSH session, and checking something inadvertently issued: > > > > > nano /var/log/messages | grep a > > > > (I was searching for something else than an 'a', but the above example shows > > the issue - about to use 'nano',

Re: bug when 'cd ..' to a directory who's parent has been deleted

On 09 Feb 2016 07:47, Chet Ramey wrote: > On 2/9/16 2:10 AM, Mike Frysinger wrote: > >> It's still an unlikely scenario. > > > > fwiw, i see it semi often when dealing with build systems: > > The unlikely scenario is somehow deleting a non-empty directory, as

Re: bug when 'cd ..' to a directory who's parent has been deleted

On 09 Feb 2016 12:22, Odd Beck wrote: > We all use our number crunching slaves differently, so I have never seen it > until yesterday, but if it's common then there might be a valid reason to > investigate this issue and maybe do some bugfixin' :) sorry, but my posting wasn't to say i think the

Re: bug when 'cd ..' to a directory who's parent has been deleted

On 08 Feb 2016 10:38, Chet Ramey wrote: > On 2/8/16 10:36 AM, Andreas Schwab wrote: > > Chet Ramey writes: > >> On 2/8/16 9:59 AM, Andreas Schwab wrote: > >>> Chet Ramey writes: > >>> > `cd ..' should fail, since the parent no longer exists, and the

Re: [PATCH/RFC] do not source/exec scripts on noexec mount points

On 15 Dec 2015 06:47, konsolebox wrote: > t On Mon, Dec 14, 2015 at 1:17 PM, Mike Frysinger <vap...@gentoo.org> wrote: > > On 13 Dec 2015 16:50, konsolebox wrote: > >> On Sun, Dec 13, 2015 at 5:01 AM, Mike Frysinger wrote: > >> > Today, if you have a scrip

Re: [PATCH/RFC] do not source/exec scripts on noexec mount points

On 13 Dec 2015 12:21, Piotr Grzybowski wrote: > On Sat, Dec 12, 2015 at 11:53 PM, Mike Frysinger wrote: > > On 12 Dec 2015 15:06, Bob Proulx wrote: > >> It will almost > >> certainly get in the way of a reasonable use case. > > > > can you name a reason

Re: [PATCH/RFC] do not source/exec scripts on noexec mount points

On 12 Dec 2015 23:05, Stephane Chazelas wrote: > 2015-12-12 16:01:26 -0500, Mike Frysinger: > [...] > > This is not a perfect solution as it can still be worked around by > > inlining the code itself: > > $ bash -c "$(cat /dev/shm/test.sh)" > > hi

Re: [PATCH/RFC] do not source/exec scripts on noexec mount points

On 13 Dec 2015 17:24, Chet Ramey wrote: > On 12/12/15 4:01 PM, Mike Frysinger wrote: > > Today, if you have a script that lives on a noexec mount point, the > > kernel will reject attempts to run it directly: > > $ printf '#!/bin/sh\necho hi\n' > /dev/shm/test.sh >

Re: [PATCH/RFC] do not source/exec scripts on noexec mount points

On 13 Dec 2015 16:50, konsolebox wrote: > On Sun, Dec 13, 2015 at 5:01 AM, Mike Frysinger wrote: > > Today, if you have a script that lives on a noexec mount point, the > > kernel will reject attempts to run it directly: > > $ printf '#!/bin/sh\necho hi\n' > /dev/shm/te

Re: [PATCH/RFC] do not source/exec scripts on noexec mount points

On 12 Dec 2015 22:12, John McKown wrote: > On Sat, Dec 12, 2015 at 3:01 PM, Mike Frysinger wrote: > > Today, if you have a script that lives on a noexec mount point, the > > kernel will reject attempts to run it directly: > > $ printf '#!/bin/sh\necho hi\n' > /dev/shm/te

Re: [PATCH/RFC] do not source/exec scripts on noexec mount points

On 12 Dec 2015 15:06, Bob Proulx wrote: > Mike Frysinger wrote: > > But bash itself has no problem running this file: > > $ bash /dev/shm/test.sh > > hi > >... > > This detracts from the security of the overall system. People > > writing scripts som

[PATCH/RFC] do not source/exec scripts on noexec mount points

From: Mike Frysinger <vap...@chromium.org> Today, if you have a script that lives on a noexec mount point, the kernel will reject attempts to run it directly: $ printf '#!/bin/sh\necho hi\n' > /dev/shm/test.sh $ chmod a+rx /dev/shm/test.sh $ /dev/shm/test.sh bash: /dev/sh

Re: bash closes fd twice.

On 11 Dec 2015 07:06, Eric Blake wrote: > On 12/11/2015 06:42 AM, Chet Ramey wrote: > > On 12/11/15 12:40 AM, Yoriyuki Yamagata wrote: > >> Dear list, > >> > >> I found that bash tries to close the same fd twice, consecutively. I’m > >> using Mac OS X Yosemite, and bash is the newest available

Re: My System get vuln in Shellshock, what should i do ?

contact the people who support your distro, or whatever hosting company you might be using -mike signature.asc Description: Digital signature

Re: loadable builtins on HP-UX

On 03 Nov 2015 18:25, Chet Ramey wrote: > On 11/3/15 4:45 PM, Greg Wooledge wrote: > > To the surprise of approximately zero people, loadable builtins don't > > fully work on HP-UX. > > > > I'll spare you any results from 10.20 because it's totally unsupported > > at this point. (It doesn't even

Re: SIGSTOP and bash's time built-in

On 26 Oct 2015 16:59, Stefan Tauner wrote: > I was creating some exercises for my students when I noticed very > strange behavior of the time built-in when sending SIGSTOP to a timed > command interactively (via ^Z): you could always install the dedicated time program and then do: $ /usr/bin/time

Re: Bug in bash 4.4-beta: suspending and restarting "man" program

what does `stty -a` show on the two systems ? what version of readline are you using on both ? -mike signature.asc Description: Digital signature

Re: updating shopt compat settings to include current version

On 16 Oct 2015 11:37, Chet Ramey wrote: > On 10/15/15 5:30 PM, Mike Frysinger wrote: > >>> the bash compat feature seems to address this nicely: our standard says > >>> we should use bash-3.2, so we set the compat level to that, and then we > >>> have muc

Re: updating shopt compat settings to include current version

On 15 Oct 2015 16:06, Chet Ramey wrote: > On 10/15/15 3:27 PM, Mike Frysinger wrote: > > our build environment relies heavily on bash. in our ebuild standard, we > > declare the min version of bash that is supported (3.2 currently). this > > way we don't have people usin

updating shopt compat settings to include current version

with bash-4.0, new compat options were introduced: shopt -s compat32 and with bash-4.3, a variable was added: export BASH_COMPAT=3.2 but things get a little weird when you want to set the compat level to the current version: $ echo $BASH_VERSION 4.3.42(1)-release

Re: updating shopt compat settings to include current version

On 15 Oct 2015 14:28, Chet Ramey wrote: > On 10/15/15 1:34 PM, Mike Frysinger wrote: > > with bash-4.0, new compat options were introduced: > > shopt -s compat32 > > and with bash-4.3, a variable was added: > > export BASH_COMPAT=3.2 > > > > but

Re: remaking bash, trying static, glibc refuses static...?

On 18 Aug 2015 13:34, Linda Walsh wrote: Then can you give any technical reason why a static lib that uses no network services (i.e. running on a mini-root ) couldn't be made available for the various calls that currently claim dynamic library support is necessary. (1)

Re: quoted compound array assignment deprecated

On 18 Aug 2015 10:51, Chet Ramey wrote: On 8/17/15 4:19 AM, isabella parakiss wrote: Quoting is necessary in a few cases: $ var=foo; declare -A arr$var=([x]=y) bash: warning: arrfoo=([x]=y): quoted compound array assignment deprecated $ var=foo; declare -A arr$var=([x]=y) bash:

Re: remaking bash, trying static, glibc refuses static...?

it is not political, nor is it related to bash at all -mike signature.asc Description: Digital signature

Re: Feature Request re: syslog and bashhist

On 10 Aug 2015 16:19, Chet Ramey wrote: On 8/9/15 1:37 PM, aixtools wrote: Via google I came across the define named config-top.h:/* #define SYSLOG_HISTORY */ Changing it (manually) to config-top.h:#define SYSLOG_HISTORY Adds syslog statements such as: Aug 9 16:52:55 x064

gcc fails to build w/bash-4.4_alpha

Configuration Information: 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/locale' -DPACKAGE='bash' -DSHELL

general loadable integration

On 14 Jul 2015 11:35, Pierre Gaston wrote: I think adoption would be difficult considering even a useful loadable builtin like finfo has not found its way into default installations, but for instance I can imagine bash programmable completion could go another level with an embedded interpreter

Re: Feature proposal/request: input line highlighting

On 11 Jun 2015 18:10, Thomas Wolff wrote: as opposed to having a fancy colored prompt, I would like to be able to set up coloring of the whole bash command input line (but not the following command output). This could be achieved by adding a variable like AFTERPROMPT_COMMAND which is

[PATCH] bash(1): ulimit: mention 512-vs-1024 byte sizes with -c/-f in POSIX mode

The change POSIX mode doc discusses these differences, but it would be useful if the ulimit section also contained the minor note about the differences in sizes for the -c/-f flags. Reported-by: Robin Johnson robb...@gentoo.org --- doc/bash.1 | 7 +-- 1 file changed, 5 insertions(+), 2

Re: Check linux 4

On 25 May 2015 15:15, isabella parakiss wrote: This is from configure.ac linux*) LOCAL_LDFLAGS=-rdynamic # allow dynamic loading case `uname -r` in 2.[[456789]]*|3*) AC_DEFINE(PGRP_PIPE) ;; esac ;; It doesn't check

Re: Check linux 4

On 25 May 2015 17:38, Chet Ramey wrote: On 5/25/15 9:15 AM, isabella parakiss wrote: This is from configure.ac linux*) LOCAL_LDFLAGS=-rdynamic # allow dynamic loading case `uname -r` in 2.[[456789]]*|3*) AC_DEFINE(PGRP_PIPE) ;;

Re: Malicious translation file can cause buffer overflow

On 01 May 2015 01:13, Pádraig Brady wrote: On 30/04/15 23:08, Trammell Hudson wrote: Description: The gettext translated messages for Done, Done(%d) and Exit %d in jobs.c are copied to a static allocated buffer. A user could set the LANGUAGE variable to point to a malicious translation

Re: Multiple patches to fix compiler warnings

please post patches inline and as a series rather than attaching a binary tarball. it makes review much harder when you do this. in fact, `git send-email` takes care of all of this for you. -mike signature.asc Description: Digital signature

Re: conflict between gcc and bash malloc lib with static link

On 08 Apr 2015 09:40, Chet Ramey wrote: I suspect the problem with malloc is that there are one or more additional symbols in the file (malloc.o) that glibc uses to satisfy some internal reference, which causes the rest of the symbols from malloc.o to be loaded, which causes conflicts with the

Re: Usage of __P vs PARAMS in histfile.c

On 08 Apr 2015 14:13, Chet Ramey wrote: On 4/8/15 11:25 AM, Evan Gates wrote: I tried compiling bash with musl-gcc and failed due to the __P macros in histfile.c While digging around it appears that __P is defined in stdc.h, but histfile.c indirectly includes rlstdc.h istead. rlstdc.h

Re: Experiment to provide a mirror of bash with detailed git history

On 21 Mar 2015 20:19, Chet Ramey wrote: On 3/16/15 4:54 PM, Eduardo A. Bustamante López wrote: I know that some people are interested in a more detailed commit history in bash's git repository. After all, it's easier for all of us to just learn to use a tool, and use that for everything.

Re: Strange file -i

On 05 Mar 2015 15:20, Chet Ramey wrote: On 3/4/15 6:07 PM, Stephane Chazelas wrote: $ perl -ne 'print if /foo/' * I just use grep directly. fwiw, git has a grep helper. this tends to be faster than a plain grep since it automatically filters out ignored files. you just have to remember

Re: Strange file -i

On 04 Mar 2015 23:07, Stephane Chazelas wrote: Note that only GNU utilities (or utilities using GNU getopt without enforcing standard mode) accept options after arguments. nice that they do too. it's super obnoxious having to manually sort flags. i hate having to use BSD systems w/out GNU

Re: [PATCH] bracketed paste support

On 30 Oct 2014 18:45, Daniel Colascione wrote: +1 -mike signature.asc Description: Digital signature

change in behavior starting with bash-4.3_p14 and $@ in [[...]]

simple enough code: foo=(0 0 0); [[ -z ${foo[@]#0} ]]; echo $? with bash-4.3_p13 and older, this would show 0. starting with bash-4.3_p14, this now shows 1. i can't tell from the thread whether this was intentional: https://lists.gnu.org/archive/html/help-bash/2014-04/msg4.html -mike

Re: Potential vulnerabilities in BASH 4.3

On Mon 11 Aug 2014 21:07:06 Hádrian R wrote: Hi, I'm Hádrien Romero Soria - @Kaiwaiata​​, I am a 16 year old boy, passionate about computer security, since more than 8h searching and finding various possible vulnerabilities in source code of bash.. I will tell you one vulnerability now, if

Re: Interactive Expect from bash Script

On Sat 29 Mar 2014 04:26:37 Esben Stien wrote: Any pointers as to what I can try? if you don't mind me asking, what's with the mixing of languages ? seems like you could accomplish all of this with python alone. are you aware of the pexepct module ? http://pexpect.sourceforge.net/

easier construction of arrays

On Thu 27 Mar 2014 08:01:45 Greg Wooledge wrote: files=() while IFS= read -r -d '' file; do files+=($file) done (find . -iname '*.mp3' ! -iname '*abba*' -print0) i've seen this construct duplicated so many times :(. i wish we had a native option for it. maybe something like:

Re: easier construction of arrays

On Thu 27 Mar 2014 19:15:13 Pierre Gaston wrote: On Thu, Mar 27, 2014 at 5:53 PM, Mike Frysinger vap...@gentoo.org wrote: On Thu 27 Mar 2014 08:01:45 Greg Wooledge wrote: files=() while IFS= read -r -d '' file; do files+=($file) done (find . -iname '*.mp3' ! -iname '*abba

Re: ls doesn't work in if statements in bash 4.3

On Fri 28 Mar 2014 10:23:17 Chris Down wrote: there's really nothing to add to Chris's wonderful post :) -mike signature.asc Description: This is a digitally signed message part.

Re: ls doesn't work in if statements in bash 4.3

On Wed 26 Mar 2014 17:45:33 billyco...@gmail.com wrote: I thought about the changes I have made recently and I had added the following into my .bashrc: eval $(dircolors -b ~/.dir_colors) I commented it out, and now everything works. I think it's still a bug, though I know how to fix it.

Re: Special built-ins not persisting assignments

On Tue 25 Mar 2014 00:39:18 Pollock, Wayne wrote: $ echo $BASH_VERSION 4.2.45(1)-release $ unset foo $ foo=bar : $ echo $foo $ === According to POSIX/SUS issue 7, assignments for special builtins should persist. So the output should be ``bar''. Is there a

Re: When a hashed pathname is deleted, search PATH

On Tue 18 Mar 2014 21:11:07 Linda Walsh wrote: Mike Frysinger wrote: On Tue 18 Mar 2014 01:04:03 Linda Walsh wrote: Chet Ramey wrote: Because the execution fails in a child process. You'd be able to fix it for that process, but would do nothing about the contents of the parent shell's

Re: When a hashed pathname is deleted, search PATH

On Tue 18 Mar 2014 01:04:03 Linda Walsh wrote: Chet Ramey wrote: Because the execution fails in a child process. You'd be able to fix it for that process, but would do nothing about the contents of the parent shell's hash table. The way the option works now is to check the hash

Re: RFE: a way to echo the arguments with quoting

On Sun 02 Mar 2014 10:12:04 Andreas Schwab wrote: Dave Yost d...@yost.com writes: I have an ugly function I wrote for zsh that does this: Sat 14:17:25 ip2 yost /Users/yost 1 634 Z% echo-quoted xyz \$foo 'a b c ' '\n' xyz '$foo' 'a b c ' '\n' Sat 14:17:53 ip2 yost /Users/yost 0 635

Re: pattern substitution expands ~ even in quoted variables

On Fri 07 Mar 2014 16:15:05 Eduardo A. Bustamante López wrote: dualbus@debian:~$ for shell in /bin/bash ~/local/bin/bash; do $shell -c 'p=foo_bar; echo ${p/_/\~} $BASH_VERSION'; done foo\~bar 4.2.37(1)-release foo~bar 4.3.0(2)-release you can get same behavior in =bash-4.2 and =bash-4.3 by

Re: Bash-4.3-rc2 available for FTP

general.c is missing traps.h include: general.c: In function ‘bash_tilde_expand’: general.c:991:3: warning: implicit declaration of function ‘any_signals_trapped’ [-Wimplicit-function-declaration] if (any_signals_trapped () 0) unicode.c is missing stdio.h

Re: Bash-4.3-rc2 available for FTP

On Thursday, January 30, 2014 10:48:34 Chet Ramey wrote: o. The shell now handles backslashes in regular expression arguments to the [[ command's =~ operator slightly differently, resulting in more consistent behavior. hmm, i seem to be running into a bug here. the bash man page

Re: Bash-4.3-rc2 available for FTP

On Thursday, January 30, 2014 23:12:18 Andreas Schwab wrote: Mike Frysinger vap...@gentoo.org writes: $ ./a.out 'a\-b' a-b regcomp(a\-b) = 0 The effect of \- in a BRE is undefined. yes, but that's kind of irrelevant for the point raised here. bash's =~ uses ERE, and passing

Re: Why bash doesn't have bug reporting site?

On Tuesday 14 January 2014 01:31:01 Yuri wrote: On 01/13/2014 12:32, Eric Blake wrote: A mailing list IS a bug reporting system. When something receives as low a volume of bug reports as bash, the mailing list archives are sufficient for tracking the status of reported bugs. It's not

Re: [PATCH] bash: add socket server support

On Thursday 14 November 2013 11:32:18 Cedric Blancher wrote: On 13 November 2013 15:46, Joel Martin wrote: On Wed, Nov 13, 2013 at 6:39 AM, Irek Szczesniak wrote: The other problems I see is: How can the script get access to the data returned by accept()? Unlike ksh93 bash4 has no

Re: [PATCH] bash: add socket server support

On Wednesday 13 November 2013 06:39:45 Irek Szczesniak wrote: On Wed, Nov 13, 2013 at 7:35 AM, Piotr Grzybowski wrote: Hi Everyone, hi Joel, the idea is nice, and I can really see that it is useful, but I would be extremely careful with introducing those kind of changes, it can be

Re: [PATCH] bash: add socket server support

On Thursday 14 November 2013 00:50:33 Piotr Grzybowski wrote: I can think of an attack, just provide me with ip address of the host :) and a root account password and login :) I agree that most systems have other abilities to do the (almost) same, but yet, all systems (that is to say many

Re: bash built-ins `true' and `false' undocumented

On Friday 27 September 2013 16:20:57 Chris Down wrote: On 2013-09-27 20:19, Roland Winkler wrote: Yet I think that the info pages are supposed to provide the definitive information about GNU software. So I still believe that it would be useful to list these builtins in the info pages, too.

Re: `printf -v foo ` does not set foo=

On Monday 24 June 2013 16:13:01 Chet Ramey wrote: On 6/17/13 1:27 AM, Mike Frysinger wrote: simple test code: unset foo printf -v foo echo ${foo+set} that does not display set. seems to have been this way since the feature was added in bash-3.1. printf returns

`printf -v foo ` does not set foo=

simple test code: unset foo printf -v foo echo ${foo+set} that does not display set. seems to have been this way since the feature was added in bash-3.1. -mike signature.asc Description: This is a digitally signed message part.

Re: currently doable? Indirect notation used w/a hash

On Tuesday 11 June 2013 03:23:29 Chris Down wrote: On 11 Jun 2013 02:19, Mike Frysinger vap...@gentoo.org wrote: On Monday 10 June 2013 18:20:44 Chris F.A. Johnson wrote: On Mon, 10 Jun 2013, Linda Walsh wrote: Point taken, but the only way such a string would be passed

Re: currently doable? Indirect notation used w/a hash

On Monday 10 June 2013 18:20:44 Chris F.A. Johnson wrote: On Mon, 10 Jun 2013, Linda Walsh wrote: Point taken, but the only way such a string would be passed as a variable name is if it was given as user input -- which would, presumably, be sanitized before being used. Programming it

Re: `declare -fp` mishandles heredoc with || statement

On Saturday 01 June 2013 17:07:33 Chet Ramey wrote: On 5/31/13 10:37 PM, Mike Frysinger wrote: simple code snippet: $ cat test.sh func() { cat / EOF || echo FAIL 11 EOF } declare -fp when run, we see the || statement is incorrectly moved to after the heredoc: $ bash

Re: Local variables overriding global constants

On Thursday 04 April 2013 10:20:50 Chet Ramey wrote: On 4/4/13 12:34 AM, Mike Frysinger wrote: would it be possible to enable a mode where you had to explicitly `declare +r` the var ? being able to simply do `local FOO` allows accidental overriding in sub funcs where the writer might

Re: Local variables overriding global constants

On Wednesday 03 April 2013 09:34:18 Chet Ramey wrote: A variable is declared readonly for a reason, and, since readonly variables may not be assigned to, I don't believe you should be able to override a readonly variable by declaring it local to a function. I did, however reluctantly, allow a

Re: Local variables overriding global constants

On Wednesday 03 April 2013 21:38:19 Chet Ramey wrote: On 4/3/13 12:31 PM, Mike Frysinger wrote: sounds like the fundamental limitation is that the person writing the code can't declare their intentions. after your compromise, they now can. if you follow the convention of putting all code

Re: autoconf 2.69?

On Wednesday 27 March 2013 11:44:32 Roman Rakus wrote: Support for the ARM 64 bit CPU architecture (aarch64) was introduced in autoconf 2.69. bash uses an earlier version of autoconf, preventing its being built. are you talking about config.{sub,guess}, or something else ? -mike

Re: autoconf 2.69?

On Wednesday 27 March 2013 14:02:57 Chet Ramey wrote: On 3/27/13 1:07 PM, Mike Frysinger wrote: On Wednesday 27 March 2013 11:44:32 Roman Rakus wrote: Support for the ARM 64 bit CPU architecture (aarch64) was introduced in autoconf 2.69. bash uses an earlier version of autoconf

random crashes when read interrupted by signal clean up modifies terminal

Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: x86_64-pc-linux-gnu-gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' - DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu' - DCONF_VENDOR='pc'

Re: random crashes when read interrupted by signal clean up modifies terminal

On Friday 08 February 2013 10:04:29 Chet Ramey wrote: Machine Type: x86_64-pc-linux-gnu Bash Version: 4.2 Patch Level: 42 Release Status: release Description: this simple testcase (distilled from [1]): Can you reproduce this using the latest devel branch code? it does not

[PATCH 2/2] use AC_CHECK_TOOL with `ar` rather than AC_CHECK_PROG

The TOOL variant will automatically search for a $host prefixed program (e.g. x86_64-pc-linux-gnu) rather than looking for `ar` only. This is useful when cross-compiling and it matches the behavior of the other tools that configure relies on (e.g. cc ranlib). Signed-off-by: Mike Frysinger vap

[PATCH 1/2] drop -i file

Guessing it was added by accident while testing. Signed-off-by: Mike Frysinger vap...@gentoo.org --- -i | 0 1 file changed, 0 insertions(+), 0 deletions(-) delete mode 100644 -i diff --git a/-i b/-i deleted file mode 100644 index e69de29..000 -- 1.8.0.2

Re: Q on Bash's self-documented POSIX compliance...

On Sunday 27 January 2013 03:22:35 Pierre Gaston wrote: On Sun, Jan 27, 2013 at 5:52 AM, John Kearney dethrop...@web.de wrote: Am 27.01.2013 01:37, schrieb Clark WANG: On Sat, Jan 26, 2013 at 1:27 PM, Linda Walsh b...@tlinx.org wrote: I noted on the bash man page that it says it will start

Re: interrupted system call when using named pipes on FreeBSD

On Friday 18 January 2013 07:55:00 Chet Ramey wrote: On 1/18/13 1:30 AM, Mike Frysinger wrote: this is somewhat a continuation of this thread: http://lists.gnu.org/archive/html/bug-bash/2008-10/msg00091.html i've gotten more or less the same report in Gentoo: http://bugs.gentoo.org

interrupted system call when using named pipes on FreeBSD

this is somewhat a continuation of this thread: http://lists.gnu.org/archive/html/bug-bash/2008-10/msg00091.html i've gotten more or less the same report in Gentoo: http://bugs.gentoo.org/447810 the simple test case is: $ cat test.sh #!/bin/bash while :; do (:) (:) (:) (:) (:) (:) (:)

  1   2   3   4   >