Hi Peng. Read the link you provided again. xmalloc is not an
alternative version of malloc. It's just a common wrapper function
around malloc. You can go and see for yourself, the definition is
here: http://git.savannah.gnu.org/cgit/bash.git/tree/xmalloc.c#n97
If you want the rest of the commands
An interactive bash is killed by SIGINT after a command to unset any
trap for SIGINT.
$ cat >/tmp/dotscript <
The artificial ulimit is to tigger the error.
My point is why bash terminates when it runs an external command that
requires a large memory. Shouldn't bash return an exit code on behalf
of the failed command and continue to the next command?
On Sunday, November 6, 2016, Eduardo Bustamante wrote:
On Nov 06 2016, Peng Yu wrote:
> My point is why bash terminates when it runs an external command that
> requires a large memory. Shouldn't bash return an exit code on behalf
> of the failed command and continue to the next command?
You have limited the amount of memory the shell itself can use,
Op 06-11-16 om 09:08 schreef Martijn Dekker:
> An interactive bash is killed by SIGINT after a command to unset any
> trap for SIGINT.
...if executed in a dot script, that is (in case that wasn't clear from
the subject line and the code examples).
Another datapoint: the same phenomenon occurs if
2016-11-04 12:29:03 +, Stephane Chazelas:
[...]
> $ LC_ALL=zh_HK.big5hkscs locale charmap
> BIG5-HKSCS
>
> Most of the problematic characters are the ones ending in 0x5c
> (which happens to be backslash in ASCII (or in BIG5-HKSCS when
> standing alone).
[...]
Those characters are also a probl
On 11/6/16 12:38 AM, Koichi MURASE wrote:
> Bash Version: 4.3
> Patch Level: 46
> Release Status: release
>
> Description:
>
> I noticed that built-in commands "printf '\uFF8E'", etc. generate
> broken surrogate pairs in Cygwin.
Thanks for the report and fix.
Chet
--
``The lyf so short, t
On 11/6/16 4:08 AM, Martijn Dekker wrote:
> An interactive bash is killed by SIGINT after a command to unset any
> trap for SIGINT.
>
> $ cat >/tmp/dotscript < trap
> trap - INT
> kill -s INT "$$"
> EOF
> $ . /tmp/dotscript
> (no output of 'trap')
> (interactive shell exits)
You're on a roll find
Peng Yu wrote:
> My point is why bash terminates when it runs an external command that
> requires a large memory. Shouldn't bash return an exit code on behalf
> of the failed command and continue to the next command?
Note that I am going to say something without looking at the source
code of bash
On 11/1/16 5:57 AM, Dan Douglas wrote:
> On Mon, Oct 24, 2016 at 8:25 AM, Chet Ramey wrote:
>> On 10/21/16 5:41 PM, L. A. Walsh wrote:
>>> On 4.3 and earlier, at least on arrays, one could have
>>> the illusion of this working w/o complaint -- and returning
>>> 0 when the array was 0-len or unset,
Hello, here is another bashbug report.
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'
-DLOCAL
> Variables in the discarded branches of conditional expressions are
> evaluated. This is caused by the function `evalcond' in expr.c. The
Sorry, `evalcond' in the previous mail should have been `expcond'.
Regards,
Koichi
12 matches
Mail list logo