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:
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 upg
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. Fix
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
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 don
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
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
>
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
>
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
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&
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 a/externs.
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 ^ (getpid
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 b/ge
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 b/arrayfunc.
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 warn
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 (string=string@entry=0x723
---
lib/readline/histexpand.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/lib/readline/histexpand.c b/lib/readline/histexpand.c
index 46a99aa62e30..13248db83048 100644
--- a/lib/readline/histexpand.c
+++ b/lib/readline/histexpand.c
@@ -26,6 +26,7 @@
#endif
#include
+#include
#if d
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
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 vers
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
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 @git.sv.gnu.org:/
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. looking
On 14 Apr 2016 09:23, Andreas Schwab wrote:
> Mike Frysinger 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'
>
> That&#
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 opinio
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 nested
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',
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 director
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 cu
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 pathname
> canonicalization should fa
On 15 Dec 2015 06:47, konsolebox wrote:
> t On Mon, Dec 14, 2015 at 1:17 PM, Mike Frysinger 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 script that lives on a noexec mount
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/t
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
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
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' > /
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' > /
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
From: Mike Frysinger
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/shm/test.sh: Permission den
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 (
contact the people who support your distro, or whatever hosting company
you might be using
-mike
signature.asc
Description: Digital signature
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
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
what does `stty -a` show on the two systems ?
what version of readline are you using on both ?
-mike
signature.asc
Description: Digital signature
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 much st
On 16 Oct 2015 14:26, Chet Ramey wrote:
> On 10/16/15 11:37 AM, Chet Ramey wrote:
> > unset BASH_COMPAT
> > shopt -u compat31 compat32 compat40 compat41
> > shopt -s compat42 2>/dev/null || :
> >
> > to set shell_compatibility_level to 42 on bash versions >= bash-4.2.
> >
> > (this needs the atta
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 us
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 thi
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
On 18 Aug 2015 21:41, Linda Walsh wrote:
> Mike Frysinger wrote:
> > On 18 Aug 2015 13:34, Linda Walsh wrote:
> > (2) it's using the nss system which lets people drop modules into the system
> > at anytime and change the overall lookups to use that. statically linking a
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)
>
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) http://www.akkad
it is not political, nor is it related to bash at all
-mike
signature.asc
Description: Digital signature
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
On 16 Jul 2015 14:53, Chet Ramey wrote:
> On 7/14/15 5:11 AM, Mike Frysinger wrote:
> > 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 d
On 14 Jul 2015 09:17, Chet Ramey wrote:
> The following patch removes the code that incorrectly optimizes the fork in
> this case. There is a much more direct way to do what I want; that will be
> in the next test release.
thanks, patch works as advertised ;)
-mike
signature.asc
Description: Di
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 interp
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 -DHAVE
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 e
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
---
doc/bash.1 | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git
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
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
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
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
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.
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
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 everythi
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 remem
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 use
On 30 Oct 2014 18:45, Daniel Colascione wrote:
+1
-mike
signature.asc
Description: Digital signature
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
signa
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
On Wed 23 Jul 2014 08:51:19 Dan Douglas wrote:
> On Wednesday, July 23, 2014 09:28:02 AM you wrote:
> > On 7/23/14, 8:22 AM, Dan Douglas wrote:
> > > Hi, from this discussion:
> > >
> > > https://github.com/koalaman/shellcheck/issues/195#issuecomment-49678200
> > >
> > > I can't find any referenc
On Thu 31 Jul 2014 23:40:18 Linda Walsh wrote:
> Chet Ramey wrote:
> > type -P echo
> >
> > ls -l $(type -P echo)
> >
> >
> > If you already have `echo' in the command hash table, type -P will return
> > it, since that's what the shell will attempt to execute.
>
> ---
> It's not in the ha
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/
i
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.
On Thu 27 Mar 2014 19:15:13 Pierre Gaston wrote:
> On Thu, Mar 27, 2014 at 5:53 PM, Mike Frysinger wrote:
> > On Thu 27 Mar 2014 08:01:45 Greg Wooledge wrote:
> > > files=()
> > > while IFS= read -r -d '' file; do
> > >
> > > file
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:
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 fi
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''.
>
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,
On Sun 16 Mar 2014 13:30:55 Andrew Kosteltsev wrote:
> When we build bash for some targets the INCLUDES variable for BUILD_CC
> contains the path to target readline headers. This path points to the
> target headers which not preferred for utilities which prepared for build
> machine.
>
> Also when
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 h
On Sun 02 Mar 2014 10:12:04 Andreas Schwab wrote:
> Dave Yost 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 63
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-
On Thursday, January 30, 2014 23:53:55 Andreas Schwab wrote:
> Mike Frysinger writes:
> > yes, but that's kind of irrelevant for the point raised here. bash's =~
> > uses ERE, and passing in REG_EXTENDED to get ERE semantics with regcomp()
> > yields the same
On Thursday, January 30, 2014 23:12:18 Andreas Schwab wrote:
> Mike Frysinger 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
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 sugge
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
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 no
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 m
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
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
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
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 hav
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.
On Tuesday 11 June 2013 03:23:29 Chris Down wrote:
> On 11 Jun 2013 02:19, "Mike Frysinger" 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
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. Progra
On Sunday 09 June 2013 16:59:15 Linda Walsh wrote:
> jida...@jidanni.org wrote:
> > All I know is there I am in emacs seeing things in the output of a
> > running bash script that I want to tweak and get busy tweaking and saving
> > changes before the script finishes, thinking that all this stuff w
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 > / < > 11
> > EOF
> > }
> > declare -fp
> >
> > when run, we see the
simple code snippet:
$ cat test.sh
func() {
cat > / < / <
signature.asc
Description: This is a digitally signed message part.
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
> >>
1 - 100 of 366 matches
Mail list logo
