for i in bash mksh; do
echo $i:
$i <<'!'
set 'a b' 'c d'
quoted="$@"
unquoted=$@
echo "$quoted"
echo "$unquoted"
!
done
here bash treats unquoted $@ on rhs differently, expanding it like $*:
bash:
a b c d
a b c d
mksh:
a b c d
a b c d
p
On Mon, 28 Feb 2011, Andres Perera wrote:
for i in bash mksh; do
echo $i:
$i <<'!'
set 'a b' 'c d'
quoted="$@"
unquoted=$@
echo "$quoted"
echo "$unquoted"
!
done
here bash treats unquoted $@ on rhs differently, expanding it like $*:
Unquoted $@
On Mon, Feb 28, 2011 at 7:41 AM, Chris F.A. Johnson
wrote:
> On Mon, 28 Feb 2011, Andres Perera wrote:
>
>> for i in bash mksh; do
>> echo $i:
>> $i <<'!'
>> set 'a b' 'c d'
>> quoted="$@"
>> unquoted=$@
>> echo "$quoted"
>> echo "$unquoted"
>> !
>> done
>>
>>
"Chris F.A. Johnson" writes:
> On Mon, 28 Feb 2011, Andres Perera wrote:
>
>> for i in bash mksh; do
>>echo $i:
>>$i <<'!'
>>set 'a b' 'c d'
>>quoted="$@"
>>unquoted=$@
>>echo "$quoted"
>>echo "$unquoted"
>>!
>> done
>>
>> here bash treats unq
> for i in bash mksh; do
> echo $i:
> $i <<'!'
> set 'a b' 'c d'
> quoted="$@"
> unquoted=$@
> echo "$quoted"
> echo "$unquoted"
> !
> done
>
> here bash treats unquoted $@ on rhs differently, expanding it like $*:
Thanks for the report. I'll
The parse_token_word() function (parse.y:4297) has a couple of off-by-one
assignments to the `token' array, which are really 2 manifestations of the
same bug.
These patches first mask the bug by solving the manifestations independently,
and then eradicate the bug by uniformly dismantling the noodl
This fixes a parsing bug that would probably never be of trouble in
practice; it is an edge case of edge cases. Nevertheless, bash should
be able to handle it without corrupting memory.
Consider the following:
$ TOKEN_DEFAULT_INITIAL_SIZE=496 # parse.y:1282
$ n=TOKEN_DEFAULT_INITIAL_SIZE
This doesn't really fix a bug; it just relaxes the required `room' that is
necessary in the allocated buffer.
>From general.h:164:
#define RESIZE_MALLOCED_BUFFER(str, cind, room, csize, sincr) \
do { \
if ((cind) + (room) >= csize) \
{ \
while ((cind) + (room) >= csi
This fixes a parsing bug that would probably never be of trouble in
practice; it is an edge case of edge cases. Nevertheless, bash should
be able to handle it without corrupting memory.
Consider the following:
$ TOKEN_DEFAULT_INITIAL_SIZE=496 # parse.y:1282
$ n=TOKEN_DEFAULT_INITIAL_SIZE
Signed-off-by: Michael Witten
---
parse.y |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/parse.y b/parse.y
index b61c4d0..eaae077 100644
--- a/parse.y
+++ b/parse.y
@@ -4453,7 +4453,7 @@ read_token_word (character)
{
peek_char = shell_getc (1);
Signed-off-by: Michael Witten
---
parse.y |8 ++--
1 files changed, 2 insertions(+), 6 deletions(-)
diff --git a/parse.y b/parse.y
index a12c4d0..b61c4d0 100644
--- a/parse.y
+++ b/parse.y
@@ -4538,17 +4538,13 @@ read_token_word (character)
shell's single-character parameter
In parse_token_word(), RESIZE_MALLOCED_BUFFER() was used in such a way
as to ensure that there is always enough room for the final '\0' character
and for a potential unquoted CTLESC or CTLNUL character (which causes an
additional CTLESC to be appended to `token').
Now, by introducing a call to RES
On 2/8/11 3:09 PM, Oleg Nesterov wrote:
> On 02/08, Chet Ramey wrote:
>>
>> On 2/8/11 1:21 PM, Oleg Nesterov wrote:
>>> Hello,
>>>
>>> We believe that the non-interactive bash doesn't handle CTRL-C
>>> correctly, please look into the attached thread from lkml for
>>> more details.
>>
>> Read http:/
On 2/8/11 7:11 PM, Ingo Molnar wrote:
> Could you try the reproducer please?
>
> Once you run it, try to stop it via Ctrl-C, and try to do this a couple of
> times.
>
> Do you consider it normal that it often takes 2-3 Ctrl-C attempts to
> interrupt that
> script, that it is not possible to s
BASH PATCH REPORT
=
Bash-Release: 4.2
Patch-ID: bash42-003
Bug-Reported-by:Clark J. Wang
Bug-Reference-ID:
Bug-Reference-URL:
http://lists.gnu.org/archive/html/bug-bash/2011-02/msg00136.html
BASH PATCH REPORT
=
Bash-Release: 4.2
Patch-ID: bash42-001
Bug-Reported-by:Juergen Daubert
Bug-Reference-ID: <20110214175132.ga19...@jue.netz>
Bug-Reference-URL:
http://lists.gnu.org/archive/htm
BASH PATCH REPORT
=
Bash-Release: 4.2
Patch-ID: bash42-004
Bug-Reported-by:Mike Frysinger
Bug-Reference-ID: <201102182106.17834.vap...@gentoo.org>
Bug-Reference-URL:
http://lists.gnu.org/archive
BASH PATCH REPORT
=
Bash-Release: 4.2
Patch-ID: bash42-002
Bug-Reported-by:Clark J. Wang
Bug-Reference-ID:
Bug-Reference-URL:
http://lists.gnu.org/archive/html/bug-bash/2011-02/msg00157.html
BASH PATCH REPORT
=
Bash-Release: 4.2
Patch-ID: bash42-005
Bug-Reported-by:Dennis Williamson
Bug-Reference-ID:
Bug-Reference-URL:
http://lists.gnu.org/archive/html/bug-bash/2011-02/msg00147.ht
On 2/9/11 9:18 AM, Oleg Nesterov wrote:
>> Consider a script that runs
>> emacs, then does other processing when emacs completes. Emacs uses SIGINT
>> internally to interrupt editing commands, but handles it and does not exit
>> as a result. Since emacs is run from a script, and job control is n
On 2/9/11 9:50 AM, Ingo Molnar wrote:
>
> * Oleg Nesterov wrote:
>
>> That is why I provided another test-case, let me repeat it:
>>
>> #!./bash
>>
>> perl -we '$SIG{INT} = sub {exit}; sleep'
>>
>> echo "Hehe, I am going to sleep after ^C"
>> sleep 100
>
> This reliably repr
On 2/9/11 4:39 PM, Oleg Nesterov wrote:
> If /bin/true gets SIGINT - everything is fine. With this particular
> test-case the problem is: ^C race race with true/false/whatever
> doing exit(any_exit_code). In this case the shell "ignores" the
> signal.
Yes, there is a race condition there. That's
On 2/9/11 4:57 PM, Linus Torvalds wrote:
> On Wed, Feb 9, 2011 at 1:18 PM, Bob Proulx wrote:
>>
>> Since the exit status of /bin/true is ignored then I think that test
>> case is flawed. I think at the least needs to check the exit status
>> of the /bin/true process.
>>
>> bash -c 'while true; d
On 2/11/11 12:27 PM, Oleg Nesterov wrote:
> On 02/11, Illia Bobyr wrote:
>>
>> Do we really need to check wait_sigint_received here?
>> If the child exits because of SIGINT was indeed received all the
>> processes on the same terminal will also receive it.
>
> Only if SIGINT was sent to pgrp (like
On 2/11/11 4:00 PM, Oleg Nesterov wrote:
> I already tried to discuss this, but you didn't reply ;) See
> http://www.mail-archive.com/bug-bash@gnu.org/msg08528.html
>
> So, if I understand correctly, you mean that
>
> #!/bin/sh
>
> interactive_application
>
> echo DONE
>
> s
On 2/11/11 6:35 PM, Linus Torvalds wrote:
> On Fri, Feb 11, 2011 at 1:30 PM, Linus Torvalds
> wrote:
>>
>> The other case is that the child process was quick and already exited.
>> You get ^C, but the child never did. When you do the waitpid(), you'll
>> never get the EINTR, because there was no a
On 2/27/11 3:23 AM, Diego Augusto Molina wrote:
> Bash Version: 4.1
> Patch Level: 7
> Release Status: release
>
> Description:
> It's difficult to explain. Better see below the particular case I had.
>
> I needed to assign the elements of an array to other, but with a preceding
> single q
On 2/23/11 8:36 AM, Nardmann, Heiko wrote:
> Hi together,
>
> short: is there any way to get informed about unset local variable while
> having option 'nounset' activated?
>
> Long: the problem with 'local' is that variable declared this way are
> visible inside the children, too. So the behaviou
On Mon, Feb 28, 2011 at 6:20 PM, Chet Ramey wrote:
>
> The patch looks good. I'll take a closer look and probably produce a
> patch for bash-4.2 based on it. Thanks for taking a look.
So I think that Oleg Nesterov is correct in that the -1 return with
errno==EINTR will never actually trigger, b
29 matches
Mail list logo
