Re: bash crash processing b=b+1 after array read

[Chet Ramey]

On 2/24/13 11:59 PM, phil colbourn wrote:

> Bash Version: 4.2
> Patch Level: 37
> Release Status: release
> 
> Description:
> 
> Within (( )), 'b=b+1' will crash bash with a segment fault if it follows an
> array read such as 'a=X[b]'.

Thanks for the report and the test case.  This was reported previously
and fixed in early January.  The fixed version is available in the `devel'
branch of the git tree on savannah.

Chet

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/

"The \". ~/.bash_aliases\" on bashrc don't load file"

[Uroz Gonzalez, Jose Luis]

Configuration Information [Automatically generated, do not change]:
Machine: i686
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS:  -DPROGRAM='bash' -DCONF_HOSTTYPE='i686' 
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i686-pc-linux-gnu' 
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL 
-DHAVE_CONFIG_H   -I.  -I../bash -I../bash/include -I../bash/lib  
-D_FORTIFY_SOURCE=2 -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat 
-Wformat-security -Werror=format-security -Wall
uname output: Linux xubuntu-ugy 3.2.0-38-generic-pae #61-Ubuntu SMP Tue Feb 19 
12:39:51 UTC 2013 i686 athlon i386 GNU/Linux
Machine Type: i686-pc-linux-gnu

Bash Version: 4.2
Patch Level: 24
Release Status: release

Description:
    On open console/terminal the aliases on .bash_aliases don't are avalaible.  
  

Repeat-By:
    A.- Open terminal
    B.- type/call any alias in ".bash_aliases" e.g. cls
    C.- Press enter
    D.- Message error "No se ha encontrado la orden «cls» pero hay 18 
similares
    cls: no se encontró la orden"

Fix:
    Prepend a slash "\" to dot on .bashrc.
    This:
    . ~/.bash_aliases
    To this:
    \. ~/.bash_aliases

Re: "The \". ~/.bash_aliases\" on bashrc don't load file"

[Chris Down]

On 2013-02-25 21:27, Uroz Gonzalez, Jose Luis wrote:
> Configuration Information [Automatically generated, do not change]:
> Machine: i686
> OS: linux-gnu
> Compiler: gcc
> Compilation CFLAGS:  -DPROGRAM='bash' -DCONF_HOSTTYPE='i686' 
> -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i686-pc-linux-gnu' 
> -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL 
> -DHAVE_CONFIG_H   -I.  -I../bash -I../bash/include -I../bash/lib  
> -D_FORTIFY_SOURCE=2 -g -O2 -fstack-protector --param=ssp-buffer-size=4 
> -Wformat -Wformat-security -Werror=format-security -Wall
> uname output: Linux xubuntu-ugy 3.2.0-38-generic-pae #61-Ubuntu SMP Tue Feb 
> 19 12:39:51 UTC 2013 i686 athlon i386 GNU/Linux
> Machine Type: i686-pc-linux-gnu
>
> Bash Version: 4.2
> Patch Level: 24
> Release Status: release
>
> Description:
>     On open console/terminal the aliases on .bash_aliases don't are 
> avalaible.    
>
> Repeat-By:
>     A.- Open terminal
>     B.- type/call any alias in ".bash_aliases" e.g. cls
>     C.- Press enter
>     D.- Message error "No se ha encontrado la orden «cls» pero hay 18 
> similares
>     cls: no se encontró la orden"
>
> Fix:
>     Prepend a slash "\" to dot on .bashrc.
>     This:
>     . ~/.bash_aliases
>     To this:
>     \. ~/.bash_aliases
>
>
>

Something is really wrong with your shell configuration if you have to do this.
What is the output of `type .`?

Chris

Re: "RE:Re: \"The \\\". ~/.bash_aliases\\\" on bashrc don't load file\""

[Chris Down]

On 2013-02-26 01:17, Uroz Gonzalez, Jose Luis wrote:
> Hi Chris,
>
> The output is:
>
>  es un alias de `cd ~' ( . is an alias of "cd ~")
>
> My apologies.
>
> Some days ago I tested aliases to best use and tested this, but not deleted.
> On restarting system I forgot completely. Sorry.
>
> From now I use first, type "alias to use".
>
> Corrected the mistake, the output is:
>
>  es una orden interna del shell (. is an internal order of the shell)
>
> Thanks for your time, and for the lesson (don't worry, every day is a 
> learning day).
>
> If I can help, please let me know.

Don't worry about it.

As an aside, your mail client is sending HTML entities (>, ", etc) in a
message with a MIME type of text/plain, which results in totally mangled mail.
Worth fixing. :-)

Best,

Chris

Re: cd -e returns syntax error

[Chris Down]

Hey,

On 2013-02-24 00:54, Dan Douglas wrote:
> On Sunday, February 24, 2013 02:43:03 PM Chris Down wrote:
> > Hi all,
> >
> > Unless I'm misunderstanding how it should work, `cd -P -e' does not work as
> > specified by the documentation. From `help cd':
>
> Yep, see: http://lists.gnu.org/archive/html/bug-bash/2013-01/msg00099.html

Sorry, didn't mean to rudely ignore your message when posting my reply. Guess I
should sync my mailbox more often...

Chris

"RE:Re: \"The \\\". ~/.bash_aliases\\\" on bashrc don't load file\""

[Uroz Gonzalez, Jose Luis]

Hi Chris,

The output is:

 es un alias de `cd ~' ( . is an alias of "cd ~")

My apologies.

Some days ago I tested aliases to best use and tested this, but not deleted.
On restarting system I forgot completely. Sorry.

>From now I use first, type "alias to use".

Corrected the mistake, the output is:

 es una orden interna del shell (. is an internal order of the shell)

Thanks for your time, and for the lesson (don't worry, every day is a learning 
day).

If I can help, please let me know.

Greetings.

Jose Luis

---Mensaje original---
On 2013-02-25 21:27, Uroz Gonzalez, Jose Luis wrote:
> Configuration Information [Automatically generated, do not change]:
> Machine: i686
> OS: linux-gnu
> Compiler: gcc
> Compilation CFLAGS:  -DPROGRAM='bash' -DCONF_HOSTTYPE='i686' 
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i686-pc-linux-gnu' 
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL 
-DHAVE_CONFIG_H   -I.  -I../bash -I../bash/include -I../bash/lib  
-D_FORTIFY_SOURCE=2 -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat 
-Wformat-security -Werror=format-security -Wall
> uname output: Linux xubuntu-ugy 3.2.0-38-generic-pae #61-Ubuntu SMP Tue 
Feb 19 12:39:51 UTC 2013 i686 athlon i386 GNU/Linux
> Machine Type: i686-pc-linux-gnu
>
> Bash Version: 4.2
> Patch Level: 24
> Release Status: release
>
> Description:
>     On open console/terminal the aliases on .bash_aliases don't are 
avalaible.    
>
> Repeat-By:
>     A.- Open terminal
>     B.- type/call any alias in ".bash_aliases" e.g. cls
>     C.- Press enter
>     D.- Message error "No se ha encontrado la orden «cls» pero hay 18 
similares
>     cls: no se encontró la orden"
>
> Fix:
>     Prepend a slash "\" to dot on .bashrc.
>     This:
>     . ~/.bash_aliases
>     To this:
>     \. ~/.bash_aliases
>
>
>

Something is really wrong with your shell configuration if you have to do this.
What is the output of `type .`?

Chris

"RE:Re: \"RE:Re: \\\"The \\\\\\\". ~/.bash_aliases\\\\\\\" on bashrc don't load ""file\\\"\""

[Uroz Gonzalez, Jose Luis]

   Hi Chris,
   Yes, I use temporally my ISP, wanad... and don't have too much control
   over.
   In few time i have my servers up and running again, and full control.
   Greetings,
   Jose Luis
   PS: Hope more luck now in format.

   ---Mensaje original---

Don't worry about it.

As an aside, your mail client is sending HTML entities (>, ", etc) in a
message with a MIME type of text/plain, which results in totally mangled mail.
Worth fixing. :-)

Best,

Chris

Should this be this way?

[Linda Walsh]

My login shell is /bin/bash (i.e. not /bin/sh); SHELL=/bin/bash as well.
Typing 'which bash' gives /bin/bash, and whence bash: bash is /bin/bash.

I had the foll0wing script which acts differently based on
whether or not it has a #!/bin/bash at the top: (i.e., as it is
displayed below, it fails; one need remove the [] from the first
line for it to work.

#[!/bin/bash]
while read fn;do
  base=${fn%.*}
  if [[ -e $base ]]; then
if [[ $base -ot $fn ]]; then echo "compressed version ($fn) seems newer"
elif [[ $base -nt $fn ]]; then echo "uncompressed version ($base)
seem newer"
else echo "both versions ($base) are same age"
fi
  else
echo "No uncompressed version of $base exists"
  fi
done < <(find . -type f -name \*.[0-9].\*[zZ]\* )
-
The error:
./manscan.sh: line 12: syntax error near unexpected token `<'
./manscan.sh: line 12: `done < <(find . -type f -name \*.[0-9].\*[zZ]\* )'

Why would this script behave differently if the first line
exists or not?  (Putting the !shell in square brackets,
made it a comment, not an interpreter spec, thus the same
effect as if it wasn't there ('cept the line number of the error is 1
less if you don't have the line! ;-)).

So...is this correct behavior for some[inane POSIX] reason? 
Seems a bit odd to me.

Re: gnu parallel in the bash manual

[Linda Walsh]

Chet Ramey wrote:
> On 2/16/13 3:50 AM, Pierre Gaston wrote:
>> I don't quite see the point of having gnu parallel discussed in the
>> bash reference manual.
> I was asked to add that in May, 2010 by Ole Tange and Richard Stallman.

Maybe now that it was done, it can be removed?

Or did they ask that parallel become part of the bash distribution?

If so, then it's entirely appropriate, but if I install bash and see
that manual section and parallel isn't there, I'd think it was
a problem with my bash distribution...

Re: Should this be this way?

[DJ Mills]

On Mon, Feb 25, 2013 at 8:03 PM, Linda Walsh  wrote:

> My login shell is /bin/bash (i.e. not /bin/sh); SHELL=/bin/bash as well.
> Typing 'which bash' gives /bin/bash, and whence bash: bash is /bin/bash.
>
> I had the foll0wing script which acts differently based on
> whether or not it has a #!/bin/bash at the top: (i.e., as it is
> displayed below, it fails; one need remove the [] from the first
> line for it to work.
> 
> #[!/bin/bash]
> while read fn;do
>   base=${fn%.*}
>   if [[ -e $base ]]; then
> if [[ $base -ot $fn ]]; then echo "compressed version ($fn) seems
> newer"
> elif [[ $base -nt $fn ]]; then echo "uncompressed version ($base)
> seem newer"
> else echo "both versions ($base) are same age"
> fi
>   else
> echo "No uncompressed version of $base exists"
>   fi
> done < <(find . -type f -name \*.[0-9].\*[zZ]\* )
> -
> The error:
> ./manscan.sh: line 12: syntax error near unexpected token `<'
> ./manscan.sh: line 12: `done < <(find . -type f -name \*.[0-9].\*[zZ]\* )'
>
> Why would this script behave differently if the first line
> exists or not?  (Putting the !shell in square brackets,
> made it a comment, not an interpreter spec, thus the same
> effect as if it wasn't there ('cept the line number of the error is 1
> less if you don't have the line! ;-)).
>
> So...is this correct behavior for some[inane POSIX] reason?
> Seems a bit odd to me.
>
>
>
>
>
>
>

How are you calling the script without a shebang? Bash called as "sh" does
disable some bashisms, process substitution being one of them.

Re: Should this be this way?

[Linda Walsh]

Sorry, forgot:
> bash --version
GNU bash, version 4.2.10(1)-release (x86_64-suse-linux-gnu)
> uname -a
Linux Ishtar 3.7.6-Isht-Van #4 SMP PREEMPT Thu Feb 7 01:34:39 PST 2013 x86_64
x86_64 x86_64 GNU/Linux
---
I just can see why it should execute differently... very weird.

Re: Should this be this way?

[DJ Mills]

On Mon, Feb 25, 2013 at 8:12 PM, Linda Walsh  wrote:

> Sorry, forgot:
> > bash --version
> GNU bash, version 4.2.10(1)-release (x86_64-suse-linux-gnu)
> > uname -a
> Linux Ishtar 3.7.6-Isht-Van #4 SMP PREEMPT Thu Feb 7 01:34:39 PST 2013
> x86_64
> x86_64 x86_64 GNU/Linux
> ---
> I just can see why it should execute differently... very weird.
>
>
>
You didn't answer the question... how did you call the script?

''sh script'' ?

Re: Should this be this way?

[Linda Walsh]

DJ Mills wrote:
> On Mon, Feb 25, 2013 at 8:12 PM, Linda Walsh  > wrote:
> 
> You didn't answer the question... how did you call the script?
> 
> ''sh script'' ?
---
I typed the script name interactively on the command line -- the way
I thought most people ran scripts.

I mentioned that everything in my ENV and usage pointed at /bin/bash.

Why would I do that, and then use 'sh script'?

Wouldn't that sorta be deliberately misleading?

Re: gnu parallel in the bash manual

[Linda Walsh]

Chet Ramey wrote:
> On 2/25/13 8:07 PM, Linda Walsh wrote:
>> Chet Ramey wrote:
>>> On 2/16/13 3:50 AM, Pierre Gaston wrote:
 I don't quite see the point of having gnu parallel discussed in the
 bash reference manual.
>>> I was asked to add that in May, 2010 by Ole Tange and Richard Stallman.
>> 
>> Maybe now that it was done, it can be removed?
> 
> I'm pretty sure that wasn't the intent of the original request.  Let's
> see if we can clean it up instead.

I'm sure, but you edited out the rest of my reasoning.
Note -- I don't feel strongly about this, one way or the other,
but at the same time, I don't feel their request, nor your response
are the best ones to take from an engineering or product perspective --
in part -- directly because of the confusion about whether or not parallel
is bundled w/bash or not.

Using it in an example would be fine... but make a section out it?  That's
a fairly strong implication for it being something that's part of bash's
official release or product.

I realize this matter is more political than technical, but still, I would
try to ask those questions of the original requestors and see if they might
not revisit their requests...?  you could even say -- a user asked if
including parallel in it's own section in the manpage meant that parallel was
going to be part of the bash distribution?

I mean it wouldn't surprise me or seem unreasonable if it was included in
the bash distribution (from a lay-person perspective).  Knowing it's a
perl-script, I'd be a bit surprised, personally, but hey, I've been wondering
if you are going to embed the perl interpreter in bash as a dynamically
loadable .so and allow perl-expressions on the command line as an option...
*str8-face*...

Re: gnu parallel in the bash manual

[John Kearney]

Am 26.02.2013 03:36, schrieb Linda Walsh:
>
> Chet Ramey wrote:
>> On 2/25/13 8:07 PM, Linda Walsh wrote:
>>> Chet Ramey wrote:
 On 2/16/13 3:50 AM, Pierre Gaston wrote:
> I don't quite see the point of having gnu parallel discussed in the
> bash reference manual.
 I was asked to add that in May, 2010 by Ole Tange and Richard Stallman.
>>> 
>>> Maybe now that it was done, it can be removed?
>> I'm pretty sure that wasn't the intent of the original request.  Let's
>> see if we can clean it up instead.
> 
>   I'm sure, but you edited out the rest of my reasoning.
> Note -- I don't feel strongly about this, one way or the other,
> but at the same time, I don't feel their request, nor your response
> are the best ones to take from an engineering or product perspective --
> in part -- directly because of the confusion about whether or not parallel
> is bundled w/bash or not.
>
> Using it in an example would be fine... but make a section out it?  That's
> a fairly strong implication for it being something that's part of bash's
> official release or product.
>
> I realize this matter is more political than technical, but still, I would
> try to ask those questions of the original requestors and see if they might
> not revisit their requests...?  you could even say -- a user asked if
> including parallel in it's own section in the manpage meant that parallel was
> going to be part of the bash distribution?
>
> I mean it wouldn't surprise me or seem unreasonable if it was included in
> the bash distribution (from a lay-person perspective).  Knowing it's a
> perl-script, I'd be a bit surprised, personally, but hey, I've been wondering
> if you are going to embed the perl interpreter in bash as a dynamically
> loadable .so and allow perl-expressions on the command line as an option...
> *str8-face*...
>
>
>
>
>
I up vote the perl integration into bash :|.

Re: Should this be this way?

[Chris Down]

On 2013-02-25 18:27, Linda Walsh wrote:
> I mentioned that everything in my ENV and usage pointed at /bin/bash.

You gave $SHELL, which is not really relevant (it doesn't necessarily reference
your login shell, or your current shell either).

> Why would I do that, and then use 'sh script'?
>
> Wouldn't that sorta be deliberately misleading?

You'd be surprised what people do without thinking about it. Seems like a
well-intentioned question to me, at least.

Either way, the code you're looking for is in `shell_execve' in `execute_cmd.c',
it should explain the behaviour that you're seeing. It's very well commented,
you should be able to find your answer there.

Chris

Re: Should this be this way?

[Linda Walsh]

Chris Down wrote:
> On 2013-02-25 18:27, Linda Walsh wrote:
>> I mentioned that everything in my ENV and usage pointed at /bin/bash.
> 
> You gave $SHELL, which is not really relevant (it doesn't necessarily 
> reference
> your login shell, or your current shell either).

I also gave my login shell and that bash was in my current
path, I thought that the default in executing a shell script
was to use my login or $SHELL value .. that both of them were the
same was my point.

>> Why would I do that, and then use 'sh script'?
>>
>> Wouldn't that sorta be deliberately misleading?
> 
> You'd be surprised what people do without thinking about it. Seems like a
> well-intentioned question to me, at least.
*sigh*

> 
> Either way, the code you're looking for is in `shell_execve' in 
> `execute_cmd.c',
> it should explain the behaviour that you're seeing. It's very well commented,
> you should be able to find your answer there.
---

Yup...

It isn't using the current value of SHELL as my shell nor the value
of my login shell.

It is forcing interpretation into /bin/sh, which I don't use.

This brings me back to the original question...
"Should this be this way?"

I think it is a bit odd to have my default shell behavior NOT be
what is in my login nor in my SHELL variable - I found it confusing to have
some "alien" shell semantics applied to my shell and couldn't figure out how
it got what it got...

Um... RFE?

Maybe execute the program under whatever shell they are currently 
running as?

Re: Should this be this way?

[Pierre Gaston]

On Tue, Feb 26, 2013 at 3:03 AM, Linda Walsh  wrote:
> My login shell is /bin/bash (i.e. not /bin/sh); SHELL=/bin/bash as well.
> Typing 'which bash' gives /bin/bash, and whence bash: bash is /bin/bash.
>
> I had the foll0wing script which acts differently based on
> whether or not it has a #!/bin/bash at the top: (i.e., as it is
> displayed below, it fails; one need remove the [] from the first
> line for it to work.
> 
> #[!/bin/bash]
> while read fn;do
>   base=${fn%.*}
>   if [[ -e $base ]]; then
> if [[ $base -ot $fn ]]; then echo "compressed version ($fn) seems newer"
> elif [[ $base -nt $fn ]]; then echo "uncompressed version ($base)
> seem newer"
> else echo "both versions ($base) are same age"
> fi
>   else
> echo "No uncompressed version of $base exists"
>   fi
> done < <(find . -type f -name \*.[0-9].\*[zZ]\* )
> -
> The error:
> ./manscan.sh: line 12: syntax error near unexpected token `<'
> ./manscan.sh: line 12: `done < <(find . -type f -name \*.[0-9].\*[zZ]\* )'
>
> Why would this script behave differently if the first line
> exists or not?  (Putting the !shell in square brackets,
> made it a comment, not an interpreter spec, thus the same
> effect as if it wasn't there ('cept the line number of the error is 1
> less if you don't have the line! ;-)).
>
> So...is this correct behavior for some[inane POSIX] reason?
> Seems a bit odd to me.
>

I don't seem to be able to reproduce it with my default configuration.

However I can reproduce it by setting (but not exporting) POSIXLY_CORRECT