On 1/24/12 4:53 AM, Jim Avera wrote:
> Bash Version: 4.2
> Patch Level: 10
> Release Status: release
>
> Description:
> set -e in (subshells) should be independent of surrounding context.
> The man page says "[set -e] applies to the shell environment and
> each subshell environment separately",
>
On 1/24/12 10:08 AM, Jonathan Andrews wrote:
> Also from previous builds:
>
> bash-4.2/bashline.c:2105: warning: Using 'endservent' in statically linked
> applications requires at runtime the shared libraries from the glibc version
> used for linking
>
> WTF ! Words fail me, I bet some c++ lov
On 01/24/2012 02:53 AM, Jim Avera wrote:
> Description:
> set -e in (subshells) should be independent of surrounding context.
> The man page says "[set -e] applies to the shell environment and
> each subshell environment separately",
> but actually set -e is prevented from working in a (subshell) i
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: 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/share/locale' -DPACK
On Tue, 2012-01-24 at 08:09 -0500, Chet Ramey wrote:
> On 1/23/12 10:17 PM, Jonathan Andrews wrote:
>
> > Im not a gcc expect, I thought the idea of the linker was also to drop
> > unused code but this seems not to be true with gcc as default.
>
> Sure, but it's the difference between all of the
On 1/23/12 10:17 PM, Jonathan Andrews wrote:
> Im not a gcc expect, I thought the idea of the linker was also to drop
> unused code but this seems not to be true with gcc as default.
Sure, but it's the difference between all of the libc functions you use
and none of them, not what you use from li
