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' -DPACKA
On 8/12/16 4:06 AM, dengke...@windriver.com wrote:
> But when I run the test line by line, it's OK.
>
> I used the version of bash is 4.3.30 on master branch, run the test on
> the qemux86-64.
The current version of bash on the master branch is 4.3.46.
--
``The lyf so short, the craft so long t
On Fri, Aug 12, 2016 at 09:59:00AM -0400, d...@fifthhorseman.net wrote:
> I think the documentation is wrong about the systemwide filename that
> bash reads when a login shell exits. the manpage says
> "/etc/bash.bash.logout", but the binary appears to be built with
> "/etc/bash.bash_logout" (note
On 8/10/16 12:06 PM, Andreas Kusalananda Kähäri wrote:
> Bash Version: 4.3
> Patch Level: 46
> Release Status: release
>
> Description:
> When declaring a variable in a function as a nameref, it can not
> be dereferenced if the variable it's a nameref to happen to have
> the same name
On 8/12/16 4:14 AM, dengke...@windriver.com wrote:
> I used the strace tool to follow it. I touch a file named lastpipe just
> contain:
>
> shopt -s lastpipe
> exit 142 | false
>
> run command:)$ ./bash --version
OK.
$ ./bash --version
GNU bash, version 4.3.46(3)-release (x86_64-unknown
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' -DPACKA
On 8/12/16 9:59 AM, d...@fifthhorseman.net wrote:
> Bash Version: 4.3
> Patch Level: 46
> Release Status: release
>
> Description:
>
> I think the documentation is wrong about the systemwide filename that
> bash reads when a login shell exits. the manpage says
> "/etc/bash.bash.logout", but the
On Fri, Aug 12, 2016 at 09:34:40AM -0400, Chet Ramey wrote:
> On 8/10/16 12:06 PM, Andreas Kusalananda Kähäri wrote:
>
> > Bash Version: 4.3
> > Patch Level: 46
> > Release Status: release
> >
> > Description:
> > When declaring a variable in a function as a nameref, it can not
> > be der
On Fri, Aug 12, 2016 at 02:22:26PM +0530, NO REPLY wrote:
> I have a few increment expressions used as ((level++)) and only one of
> those is giving an error. When used with set -e, bash aborts
> execution. Using ERR trap, I was able to identify the expression.
http://mywiki.wooledge.
On 8/12/16 11:30 AM, Andreas Kusalananda Kähäri wrote:
> My workaround is currently to slightly obfuscate the name of the local
> nameref previously called "var" in each function so that their names
> won't clash within the library and so that it's less likely that they
> clash with global variabl
On 8/12/16 4:52 AM, NO REPLY wrote:
> Bash Version: 4.3
> Patch Level: 11
> Release Status: release
>
> Description:
> I have a few increment expressions used as ((level++)) and only one of
> those is giving an error. When used with set -e, bash aborts
> execution. Using ERR trap, I
But when I run the test line by line, it's OK.
I used the version of bash is 4.3.30 on master branch, run the test on
the qemux86-64.
On 2016年08月10日 19:16, Chet Ramey wrote:
On 8/10/16 3:32 AM, dengke...@windriver.com wrote:
Hi all
When I run the bash test lastpipe.tests, there were some erro
I used the strace tool to follow it. I touch a file named lastpipe just
contain:
shopt -s lastpipe
exit 142 | false
run command:
$ strace /bin/bash lastpipe
the output:
read(3, "shopt -s lastpipe\nexit 142 | fal"..., 80) = 35
lseek(3, 0, SEEK_SET) = 0
13 matches
Mail list logo