Configuration Information [Automatically generated, do not change]:
Machine: i686
OS: linux-gnu
Compiler: /usr/local/bin/gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i686'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i686-pc-linux-gnu'
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr1/local/bash/
Configuration Information [Automatically generated, do not change]:
Machine: i586
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i586'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i586-mandriva-linux-gnu'
-DCONF_VENDOR='mandriva' -DLOCALEDIR='/usr/share/locale'
Configuration Information [Automatically generated, do not change]:
Machine: sparc
OS: solaris2.8
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='sparc'
-DCONF_OSTYPE='solaris2.8' -DCONF_MACHTYPE='sparc-sun-solaris2.8'
-DCONF_VENDOR='sun' -DLOCALEDIR='/sw/opensrc/gnu/share/lo
On Sun, Feb 05, 2006 at 07:02:10PM -0500, Chris F.A. Johnson wrote:
> On Sun, 5 Feb 2006, Felipe Kellermann wrote:
>
> >On Thu, 2 Feb 2006 11:13pm -0500, Mike Frysinger wrote:
> >
> >>upper case or lower case ... if 'tr' was a bash builtin, then that'd work
> >>with some `echo | tr` magic, but it
Hi,
I posted two patches for memory leaks in bash-3.0. One of them has
made it into bash-3.1, but the other has not. Here is the missing
one:
On Wed, Dec 07, 2005 at 06:10:07PM +, Tim Waugh wrote:
> There is at least one memory leak in the read builtin in bash-3.0. To
> demonstrate it, tr
> Machine Type: sparc-sun-solaris2.8
>
> Bash Version: 3.1
> Patch Level: 0
> Release Status: release
>
> Description:
> Assigning arrays using
> testvar=( $(echo A) $(echo B) )
> is accepted in bash-3.1.0. However, using the
> same in an eval-construct
>
> Machine Type: i586-mandriva-linux-gnu
>
> Bash Version: 3.0
> Patch Level: 16
> Release Status: release
>
> Description:
> Hello,
> I have problem with my bash. He doesn't read my
> /etc/profile, /etc/bashrc, ~/.bash_profile and ~/.bashrc
Be aware that bash doesn'
Configuration Information [Automatically generated, do not change]:
Machine: sparc
OS: solaris2.8
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='sparc'
-DCONF_OSTYPE='solaris2.8' -DCONF_MACHTYPE='sparc-sun-solaris2.8'
-DCONF_VENDOR='sun' -DLOCALEDIR='/sw/opensrc/gnu/share/lo
[EMAIL PROTECTED] wrote:
> Normally, the eval builtin used in functions to set variables
> makes these variables available globally otutside the function.
> However, when the function gets input from a pipline, the variables
> are set only locally.
Read the bash FAQ, entry
> Machine Type: sparc-sun-solaris2.8
>
> Bash Version: 3.1
> Patch Level: 0
> Release Status: release
>
> Description:
> Normally, the eval builtin used in functions to set variables
> makes these variables available globally otutside the function.
> However, when the function g
On Mon, Feb 13, 2006 at 04:19:42PM +0100, [EMAIL PROTECTED] wrote:
> Configuration Information [Automatically generated, do not change]:
> Machine: sparc
> OS: solaris2.8
> Compiler: gcc
> Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='sparc'
> -DCONF_OSTYPE='solaris2.8' -DCONF_MACHTYPE='s
Hi,
I build bash v3.1 for cross-target. I configured bash like this:
CC= AR= RANLIB=
/configure --host= --target=
--build=i686-pc-linux-gnu --disable-nls --prefix=
1. To complete build I had to comment out running test on cross-target.
2. Build picks up headers from /usr/include, not from the di
Yuri Karlsbrun wrote:
> Hi,
>
> I build bash v3.1 for cross-target. I configured bash like this:
>
> CC= AR= RANLIB=
> /configure --host= --target=
> --build=i686-pc-linux-gnu --disable-nls --prefix=
>
> 1. To complete build I had to comment out running test on cross-target.
The usual solution
[EMAIL PROTECTED] wrote:
> Configuration Information [Automatically generated, do not change]:
> Machine: i686
> OS: linux-gnu
> Compiler: /usr/local/bin/gcc
> Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i686'
> -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i686-pc-linux-gnu'
> -DCONF_VEN
> Bash doesn't specify /usr/include at all. Isn't it the responsibility
> of the compiler to choose an appropriate set of default include
> directories?
>
When I build other applications for my target, I have no problems with
headers. When I explicitly included header's path
(CPPFLAGS="-I"), it
Yong Lu wrote:
>
> Hi, thanks for your reply! With bash2, I can simply modify the output
> of `bind -vp` and read back the keybinding by `bind -f`. How can I
> make it to work with bash3 too?
If you run with convert-meta disabled, take the output and convert the
key sequences that begin with
On Monday 13 February 2006 15:40, Chet Ramey wrote:
> Yuri Karlsbrun wrote:
> > I build bash v3.1 for cross-target. I configured bash like this:
> >
> > CC= AR= RANLIB=
> > /configure --host=
> > --target= --build=i686-pc-linux-gnu --disable-nls
> > --prefix=
> >
> > 1. To complete build I had to c
> -Original Message-
> From: Mike Frysinger [mailto:[EMAIL PROTECTED]
> > > 1. To complete build I had to comment out running test on cross-
> target.
> >
> > The usual solution for this is to create a config.cache file with the
> > correct values for the cache variables in question.
>
>
On Monday 13 February 2006 19:31, Yuri Karlsbrun wrote:
> You just cannot execute cross-compiled code on native platform...
yes, i know that, that isnt what i asked you
> Also mksignames utility is built using native headers (from /usr/include),
> so signal name translation is incorrect for cross
hmm ... seems my e-mail client crashed when i sent the last message ...
On Monday 13 February 2006 19:31, Yuri Karlsbrun wrote:
> You just cannot execute cross-compiled code on native platform...
yes, i know that, that isnt what i asked you
> Also mksignames utility is built using native headers
20 matches
Mail list logo