On Wednesday, February 02, 2011 08:56:24 Chet Ramey wrote:
> The second release candidate of bash-4.2 is now available with the URL
>
> ftp://ftp.cwru.edu/pub/bash/bash-4.2-rc2.tar.gz
- braces.c:mkseq() is using an intmax_t type for the length in the asprintf
call when it needs to be an int. a
On Wednesday, February 02, 2011 21:49:38 Chet Ramey wrote:
> On 2/2/11 6:27 PM, Mike Frysinger wrote:
> > - lib/glob/smatch.c needs externs.h for mbsmbchar. seems like externs.h
> > could do with including bashtypes.h/command.h/general.h too since it
> > needs basic ty
On Wednesday, February 16, 2011 23:51:16 Clark J. Wang wrote:
> I know little about open source development process (and control?). I just
> don't know where to get the bash code (like CVS, SVN respository) before
> it's released. I think it's better to make it open to more people so
> everyone can
this simple code no longer works in bash-4.2:
$ f=abc; echo ${f##""a}
abc
same goes for ${f//""a} and ${f%%""c}, and perhaps more operations
removing the quotes, or quoting the single char in question, makes it work:
$ f=abc; echo ${f##a} ${f##"a"}
bc bc
the original bug report uses variables in
On Friday, February 18, 2011 23:17:11 Chet Ramey wrote:
> On 2/18/11 9:06 PM, Mike Frysinger wrote:
> > this simple code no longer works in bash-4.2:
> > $ f=abc; echo ${f##""a}
> > abc
> > same goes for ${f//""a} and ${f%%""c}, and per
On Saturday, March 19, 2011 17:33:36 Chet Ramey wrote:
> On 3/18/11 9:42 PM, Zeev Tarantov wrote:
> > x86_64-pc-linux-gnu-gcc: error: \: No such file or directory
> > x86_64-pc-linux-gnu-gcc: error: \: No such file or directory
> > x86_64-pc-linux-gnu-gcc: error: \: No such file or directory
> > x8
On Mon, Mar 21, 2011 at 8:32 AM, Greg Wooledge wrote:
> On Sat, Mar 19, 2011 at 09:52:05PM +, Zeev Tarantov wrote:
>> configure:3122: checking for C compiler default output file name
>> configure:3144: x86_64-pc-linux-gnu-gcc -g -O2 -flto
>> -DDEFAULT_PATH_VALUE='"/usr/local/sbin:/usr/local/bin
On Wed, Mar 23, 2011 at 2:51 PM, Ralf Thielow wrote:
> i've found a german misspelling in command "cd".
> Where can i fix it?
please use bug-bash, not bash-announce
a bit odd announce isnt moderated so only people like Chet can announce ...
-mike
On Mon, Mar 28, 2011 at 2:25 PM, Greg Wooledge wrote:
> In any case, I see no benefit to changing how [[ works. A change would
> just cause more confusion.
and probably break many existing scripts
-mike
seems to be just like the bug fixed in bash41-006, but with a diff for loop
style. simple example:
f() {
for (( :; :; )) ; do
cat <
signature.asc
Description: This is a digitally signed message part.
On Tuesday, April 19, 2011 16:38:57 Chet Ramey wrote:
> > seems to be just like the bug fixed in bash41-006, but with a diff for
> > loop style. simple example:
>
> Try the attached patch and let me know the results. It fixes this
> case and a couple of others.
sorry for the delay ... that patch
On Sunday, May 29, 2011 22:18:33 Bradley M. Kuhn wrote:
> It's been two years since this discussion began
and there have been requests older than that. you just found the most
"recent".
-mike
signature.asc
Description: This is a digitally signed message part.
On Saturday, June 18, 2011 16:37:18 John Williams wrote:
> Is this a bash bug, or intentional behavior?
it's coming from the kernel, not bash
post the output of `mount` and make sure that it doesnt have the "noexec" flag
-mike
signature.asc
Description: This is a digitally signed message part.
On Monday, August 08, 2011 21:20:29 Chet Ramey wrote:
> On 8/8/11 8:53 AM, Eric Blake wrote:
> > However, you are on to something - since bash allows 'exit -1' as an
> > extension, it should similarly allow 'return -1' as the same sort of
> > extension. The fact that bash accepts 'exit -1' and 'ex
On Monday, September 19, 2011 01:18:02 Roger wrote:
> I'm stumped on this as my history is in the format of:
>
> $ tail ~/.bash_history
> #1316296633
> man bash
> #1316296664
> bash -xv
> #1316372056
> screen -rd
> #1316375930
> exit
> #1316392889
> exit
>
> Is there a method of purging the histo
the current yacc rules allow multiple runs to generate the same files. usually
this doesn't come up as the generated files are shipped in the tarball, but
when you modify parse.y (applying a patch or developing or whatever), you can
hit this problem.
simple way of showing this:
make -j y.
the current code generates a bunch of local libraries in subdirs and then
links bash against that. those subdirs sometimes need version.h. so they
have a rule to change back up to the parent dir and build version.h (which is
fine). the trouble is that the top level objects and the subdirs are al
the top level Makefile will recurse into the defdir for multiple targets
(libbuiltins.a, common.o, bashgetopt.o, builtext.h), and since these do not
have any declared interdependencies, parallel makes will recurse into the
subdir and build the respective targets.
nothing depends on common.o or bas
On Friday 11 November 2011 00:48:59 Clark J. Wang wrote:
> In my company all the people share a few of Solaris servers which use NIS
> to manage user accounts. The bad thing is that some servers' root passwords
> are well known so anybody can easily su to my account to access my files.
> To protect
On Sunday 20 November 2011 11:54:42 Pierre Gaston wrote:
> On Sun, Nov 20, 2011 at 6:43 PM, Peng Yu wrote:
> > Hi,
> >
> > I don't see if there is a way to directly modify $@. I know 'shift'.
> > But I'm wondering if there is any other way to modify $@.
> >
> > ~$ 1=x
> > -bash: 1=x: command not
On Wednesday 23 November 2011 23:23:43 Chet Ramey wrote:
> I spent a little while messing around with git over the past couple of
> days, and ended up updating the bash git repository on savannah
> (http://git.savannah.gnu.org/cgit/bash.git to browse the sources).
> Bash-4.2 patch 20 is the head of
On Friday 25 November 2011 22:28:49 Chet Ramey wrote:
> On 11/24/11 12:36 PM, Mike Frysinger wrote:
> > On Wednesday 23 November 2011 23:23:43 Chet Ramey wrote:
> >> I spent a little while messing around with git over the past couple of
> >> days, and ended up updating
On Sunday 27 November 2011 21:31:16 Chet Ramey wrote:
> On 11/26/11 2:56 AM, Mike Frysinger wrote:
> >> Thanks. I have bash sources going back a number of years, and I can get
> >> them into git. It will just take me a while.
> >>
> >> The question
On Thursday 01 December 2011 19:01:50 james.cuze...@lyraphase.com wrote:
> Description:
> popd does not appear to return a nonzero exit status when the directory
> stack is empty anymore.
works for me:
$ echo $BASH_VERSION ; popd ; echo $?
4.2.20(1)-release
bash: popd: directory stack empty
On Tuesday 20 December 2011 17:18:16 kc123 wrote:
> For example, my script below called crond.sh:
> ...
> content=`ps auxw | grep [c]rond| awk '{print $11}'`
> ...
> and output is:
> CONTENT: /bin/bash /bin/bash crond
>
> Why are there 2 extra arguments printed (/bin/bash) ?
because you grepped y
On Tuesday 03 January 2012 08:48:27 nick humphrey wrote:
> Description:
> i dont know if the bug is a bash bug or openssl or echo, but when i
> echo a string and pipe it to openssl, the
> output comes on the same line as the prompt instead of a new line. it makes
> the output hard to read b
can't tell if this is a bug or a feature.
FOO= BAR=bar
: ${FOO:=${BAR}
echo $FOO
i'd expect an error, or FOO to contain those excess braces. instead, FOO is
just "bar".
-mike
signature.asc
Description: This is a digitally signed message part.
On Wednesday 29 February 2012 17:53:21 Linda Walsh wrote:
> Eric Blake wrote:
> > On 02/29/2012 12:26 PM, Linda Walsh wrote:
> >>> Any pathname that contains a / should not be subject to PATH searching.
> >
> > Agreed - as this behavior is _mandated_ by POSIX, for both sh(1) and for
> > execlp(2)
On Tuesday 20 March 2012 15:55:18 Chet Ramey wrote:
> or the even simpler
>
> f()
> {
> f | f &
>
> }
> f
i like the variant that uses ":" instead of "f":
:(){ :|:& };:
-mike
signature.asc
Description: This is a digitally signed message part.
On Tuesday 27 March 2012 08:08:33 Pierre Gaston wrote:
> On Tue, Mar 27, 2012 at 3:00 PM, Joachim Schmitz wrote:
> > dennis.birkh...@rwth-aachen.de wrote:
> > >
> >
> >> Bash Version: 4.2
> >> Patch Level: 24
> >> Release Status: release
> >
> > Interesting, seems the announcements dor patches 21
On Saturday 07 April 2012 16:45:55 Linda Walsh wrote:
> Is it an accidental omission from the bash manpage?
it's in the man page. read the "Arithmetic Expansion" section.
-mike
signature.asc
Description: This is a digitally signed message part.
first set your locale to something unicode based:
export LC_ALL=en_US.UTF-8
then try the simple script (from Ulrich Müller):
$ cat test.sh
shopt -s extglob
text="aaaäöü"
echo "${text} ${text//?aa} ${text//\aaa}"
with bash-4.1_p2, i get:
aaaäöü äöü äöü
but with bash-4.2_p8 ... 4.2_p24 (just what
if you disable readline, the complete.def code fails to build. simple patch
below (not sure if it's correct, but at least gets the conversation going).
-mike
--- a/builtins/complete.def
+++ b/builtins/complete.def
@@ -49,6 +49,8 @@ $END
#include
+#ifdef READLINE
+
#include
#include ".
On Monday 23 April 2012 18:57:05 Chet Ramey wrote:
> On 4/23/12 12:22 AM, Mike Frysinger wrote:
> > if you disable readline, the complete.def code fails to build. simple
> > patch below (not sure if it's correct, but at least gets the
> > conversation going).
>
&
On Monday 23 April 2012 20:08:26 Chet Ramey wrote:
> On 4/23/12 7:40 PM, Mike Frysinger wrote:
> > On Monday 23 April 2012 18:57:05 Chet Ramey wrote:
> >> On 4/23/12 12:22 AM, Mike Frysinger wrote:
> >>> if you disable readline, the complete.def code fails to build.
On Tuesday 24 April 2012 08:23:04 Chet Ramey wrote:
> On 4/24/12 12:00 AM, Mike Frysinger wrote:
> >> OK, so you've stripped the local readline copy out of the source tree?
> >
> > yes
> >
> >> Then configured it to build with a system readli
On Tuesday 24 April 2012 15:49:57 Chet Ramey wrote:
> On 4/24/12 10:46 AM, Mike Frysinger wrote:
> > On Tuesday 24 April 2012 08:23:04 Chet Ramey wrote:
> >> On 4/24/12 12:00 AM, Mike Frysinger wrote:
> >>>> OK, so you've stripped the local readline copy ou
On Thursday 26 April 2012 23:47:39 Linda Walsh wrote:
> Anything else you wanna tell me NEVER/ALWAYS to do?
try ALWAYS being polite. but i guess that'll NEVER happen.
oh well, thankfully kmail can auto-mute based on sender.
-mike
signature.asc
Description: This is a digitally signed message pa
On Thursday 03 May 2012 16:12:17 John Kearney wrote:
> I tend to do something more like this
>
> function runJobParrell {
> local mjobCnt=${1} && shift
> jcnt=0
> function WrapJob {
> "${@}"
> kill -s USR2 $$
> }
neat trick. all my para
On Friday 04 May 2012 08:55:42 Chet Ramey wrote:
> On 5/3/12 2:49 PM, Colin McEwan wrote:
> > What I would really *like* would be an extension to the shell which
> > implements the same sort of parallelism-limiting / 'process pooling'
> > found in make or 'parallel' via an operator in the shell lan
On Friday 04 May 2012 12:44:32 Greg Wooledge wrote:
> On Fri, May 04, 2012 at 12:41:03PM -0400, Mike Frysinger wrote:
> > i wish there was a way to use `wait` that didn't block until all the pids
> > returned. maybe a dedicated option, or a shopt to enable this, or a new
&g
On Friday 04 May 2012 13:46:32 Andreas Schwab wrote:
> Mike Frysinger writes:
> > i wish there was a way to use `wait` that didn't block until all the pids
> > returned. maybe a dedicated option, or a shopt to enable this, or a new
> > command.
> >
> > for
On Friday 04 May 2012 15:02:27 John Kearney wrote:
> Am 04.05.2012 20:53, schrieb Mike Frysinger:
> > On Friday 04 May 2012 13:46:32 Andreas Schwab wrote:
> >> Mike Frysinger writes:
> >>> i wish there was a way to use `wait` that didn't block until all the
>
On Friday 04 May 2012 16:17:02 Chet Ramey wrote:
> On 5/4/12 2:53 PM, Mike Frysinger wrote:
> > it might be a little racy (wrt checking cnt >= 10 and then doing a wait),
> > but this is good enough for some things. it does lose visibility into
> > which pids are live v
On Friday 04 May 2012 15:25:25 John Kearney wrote:
> Am 04.05.2012 21:13, schrieb Mike Frysinger:
> > On Friday 04 May 2012 15:02:27 John Kearney wrote:
> >> Am 04.05.2012 20:53, schrieb Mike Frysinger:
> >>> On Friday 04 May 2012 13:46:32 Andreas Schwab wrote:
On Saturday 05 May 2012 04:28:50 John Kearney wrote:
> Am 05.05.2012 06:35, schrieb Mike Frysinger:
> > On Friday 04 May 2012 15:25:25 John Kearney wrote:
> >> Am 04.05.2012 21:13, schrieb Mike Frysinger:
> >>> On Friday 04 May 2012 15:02:27 John Kearney wrote:
>
On Saturday 05 May 2012 23:25:26 John Kearney wrote:
> Am 05.05.2012 06:28, schrieb Mike Frysinger:
> > On Friday 04 May 2012 16:17:02 Chet Ramey wrote:
> >> On 5/4/12 2:53 PM, Mike Frysinger wrote:
> >>> it might be a little racy (wrt checking cnt >= 10 and then
On Sunday 06 May 2012 03:25:27 John Kearney wrote:
> Am 06.05.2012 08:28, schrieb Mike Frysinger:
> > On Saturday 05 May 2012 23:25:26 John Kearney wrote:
> >> Am 05.05.2012 06:28, schrieb Mike Frysinger:
> >>> On Friday 04 May 2012 16:17:02 Chet Ramey wrote:
On Monday 07 May 2012 09:08:33 Chet Ramey wrote:
> On 5/5/12 12:28 AM, Mike Frysinger wrote:
> > On Friday 04 May 2012 16:17:02 Chet Ramey wrote:
> >> On 5/4/12 2:53 PM, Mike Frysinger wrote:
> >>> it might be a little racy (wrt checking cnt >= 10 and then doin
in light of the recent discussion, i thought i could switch posix mode on/off
on the fly so that i restricted myself to this mode only when using `wait`.
unfortunately, that randomly crashes bash :). simple test case:
$ cat test.sh
#!/bin/bash
max=20
num=0
set -m
#set -o posix
trap ': $(( --nu
On Friday 11 May 2012 13:37:58 Chet Ramey wrote:
> On 5/11/12 11:43 AM, Mike Frysinger wrote:
> > in light of the recent discussion, i thought i could switch posix mode
> > on/off on the fly so that i restricted myself to this mode only when
> > using `wait`.
> > u
On Friday 11 May 2012 14:25:08 Chet Ramey wrote:
> On 5/11/12 11:43 AM, Mike Frysinger wrote:
> > in light of the recent discussion, i thought i could switch posix mode
> > on/off on the fly so that i restricted myself to this mode only when
> > using `wait`.
>
> >
On Thursday 16 August 2012 20:36:45 Keith Clifford wrote:
> some_var=# What I thought was a comment.
>
> The '#' is eaten by the variable assignment so that some_var gets a null
> value and the rest of the line is not treated like a command.
this is correct (if sometimes confusing to people) beha
On Tuesday 21 August 2012 07:45:49 Ondrej Oprala wrote:
> unless this bug is already fixed in some way
yes, please retest with very latest bash-4.2 and the released patchsets
-mike
signature.asc
Description: This is a digitally signed message part.
consider this simple code:
$ cat test.sh
#!/bin/bash
trap 'echo $BASH_COMMAND; exit 1' ERR
set -e
true
(false)
true
when run, we see:
$ ./test.sh
true 1
this can be confusing when utilized with automatic backtraces :(
even when using errtrace and debugtrace, BASH_COMMAND is incorrect
-mike
si
On Wednesday 22 August 2012 12:30:11 Mike Frysinger wrote:
> consider this simple code:
>
> $ cat test.sh
> #!/bin/bash
> trap 'echo $BASH_COMMAND; exit 1' ERR
> set -e
> true
> (false)
> true
>
> when run, we see:
> $ ./test.sh
> true 1
err,
Rather than using 1 byte reads, use the existing cache read logic.
This could be sped up more, but this change is not as invasive and
should (hopefully) be fairly safe.
Signed-off-by: Mike Frysinger
---
builtins/read.def | 21 -
externs.h | 1 +
lib/sh/zread.c
On Tuesday 01 January 2013 15:10:00 Chet Ramey wrote:
> On 1/1/13 2:49 PM, Aharon Robbins wrote:
> > Michael Williamson wrote:
> >> I have a complaint. Apparently, when unknowingly attempting to run a
> >> 32-bit executable file on a 64-bit computer, bash gives the error
> >> message "No such file
On Wednesday 02 January 2013 09:47:10 Roman Rakus wrote:
> On 01/02/2013 03:31 PM, Eric Blake wrote:
> > On 01/02/2013 07:28 AM, Michael Williamson wrote:
> >> Thanks for your explanation. Now I have another question.
> >> Why is the error message for ENOENT simply
> >> "No such file or directory",
On Wednesday 02 January 2013 07:07:49 Roman Rakus wrote:
> On 01/02/2013 02:25 AM, Mike Frysinger wrote:
> > On Tuesday 01 January 2013 15:10:00 Chet Ramey wrote:
> >> On 1/1/13 2:49 PM, Aharon Robbins wrote:
> >>> Michael Williamson wrote:
> >>>> I h
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
(:)& (:)& (:)& (:)& (:)& (:)& (
On Monday 19 November 2012 19:46:17 Mike Frysinger wrote:
> Rather than using 1 byte reads, use the existing cache read logic.
> This could be sped up more, but this change is not as invasive and
> should (hopefully) be fairly safe.
ping ...
-mike
signature.asc
Description: This is a
On Friday 18 January 2013 07:49:22 Chet Ramey wrote:
> On 1/18/13 1:31 AM, Mike Frysinger wrote:
> > On Monday 19 November 2012 19:46:17 Mike Frysinger wrote:
> >> Rather than using 1 byte reads, use the existing cache read logic.
> >> This could be sped up more, but thi
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
On Sunday 27 January 2013 03:22:35 Pierre Gaston wrote:
> On Sun, Jan 27, 2013 at 5:52 AM, John Kearney wrote:
> > Am 27.01.2013 01:37, schrieb Clark WANG:
> >> On Sat, Jan 26, 2013 at 1:27 PM, Linda Walsh wrote:
> >>> I noted on the bash man page that it says it will start in posix
> >>> complia
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 Frysi
Guessing it was added by accident while testing.
Signed-off-by: Mike Frysinger
---
-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
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' -DLOCALEDIR='/usr/s
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 co
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
signature
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
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, allo
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
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
> >>
simple code snippet:
$ cat test.sh
func() {
cat > / < / <
signature.asc
Description: This is a digitally signed message part.
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
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 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 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
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 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
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 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 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 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 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
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 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
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 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 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 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 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 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 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 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 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 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 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 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.
1 - 100 of 366 matches
Mail list logo
