On 6/2/17 5:30 PM, Siteshwar Vashisht wrote:
> Bash Version: 4.3
> Patch Level: 43
> Release Status: release
>
> Description:
> If the modified timestamp of 2 files differ by less than 1 second,
> test builtin sometimes returns incorrect result. It happens because
> HAVE_STRUCT_STAT_ST_
On 6/3/17 1:15 PM, Pranav Deshpande wrote:
> Hello,
> Sorry for the late reply.
>
> My solution is to change *line 294* of builtins/read.def.
>
> Change
> if (code == 0 || *intval < 0* || intval != (int)intval)
>
> to
>
> if (code == 0 || i*ntval <= 0* || intval != (int)intval)
That's a fine s
On 6/4/17 6:36 AM, Jörn Hees wrote:
> Hi,
>
> in the HISTORY section of the man-page it says:
>
>> ... When the history file
>> is read, lines beginning with the history comment character followed
>> immediately by a digit are interpreted
>> as timestamps for the preceding history line.
>
> s
On Tue, 2017-06-06 at 10:20 -0400, Greg Wooledge wrote:
> (OK, in reality, I am not taking any of this seriously. This entire
> proposal and discussion are like some bizarre fantasy land to me. Bash
> is a SHELL, for god's sake. Not a serious programming language. Even
> serious programming lan
Instead of talking in terms of seriousness, it may be more use to think in
terms of formality.
Even in gramitically strong and formal languages variable and function names
are restricted in the characters they may use. This is not just because it
makes the parsing simpler but because it simpli
On 08/06/2560 04:33, Dethrophes wrote:
> This would be a bad idea in the same way that having control characters in
> filenames is a bad idea, just because you can do something doesn't mean you
> should.
I would personally advocate NOT to use it in code. But then, I am
biassed by upbringing towa
Found by running the test suite under ASAN.
=
==3298==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 12 byte(s) in 1 object(s) allocated from:
#0 0x7f2b94db1d28 in malloc
(/usr/lib/x86_64-linux-gn
