With the recent inherit_errexit , the Bash team seems to have finally
bumped into a workable way to fix errexit which has been broken for
decades (https://mywiki.wooledge.org/BashFAQ/105).
Instead of trying to invent a replacement shell option for that and hope
to get it right on the first try
Chet Ramey () wrote:
> On 12/23/18 12:01 PM, Bize Ma wrote:
>
{…}
> > Both command line above should have printed "hello".
>
> No. 0 is the only valid subscript for a non-array variable. The difference
> between bash and other shells that implement this feature is that bash
> warns about negative
Chet Ramey () wrote:
> On 12/23/18 12:07 PM, Bize Ma wrote:
{...}
> > Have you been able to "take a look" ?
>
> Yes, as a matter of fact. Look at the changelog for the day or two around
> the date of the referenced messages.
>
I am pretty sure that I will not understand the finer details of t
Eduardo Bustamante () wrote:
>
> (...)
> What if instead of
> complaining you do something about it, like, fixing the problem (send
> a patch)?
>
You are assuming that if I take a look at the c code I will be able to read
it,
then understand it, and then make meaningful, or even reasonable cha
>
> Sure, it's a candidate for inclusion in a future version. I wouldn't object
> if someone wanted to do a sample implementation, since it changes how the
> variable value is parsed.
>
I only wish I knew enough C to make any (even small) positive
recommendation.
On 12/27/18 6:58 PM, Peng Yu wrote:
> Since the main() function is already there, why there is not already
> an easy way to compile it? How do you do unit-testing then for the
> code?
That code hasn't really changed in almost twenty years. All the testing
was done long ago.
(I just changed it re
On 12/27/18 6:58 PM, Peng Yu wrote:
>> So you need a definition for xmalloc. The easiest thing to do is to add
>> an xmalloc function in the TEST_HASHING block, or you could follow the
>> directions in the comment there.
>>
>> Sooner or later, you're going to have to pick this stuff up on your own
On 12/27/18 11:32 PM, Peng Yu wrote:
>> You're whacking moles. Use a profiler. That's what they're for.
>
> I've already shown that $() is a major problem to slow down the speed
> and I have reduced using its usage in my code and significantly
> improved the performance.
This isn't a major ded
On 12/27/18 3:11 PM, Martijn Dekker wrote:
> Consistency might be a better argument. If [[ -v foo ]] is equivalent to [[
> -n ${foo+s} ]] for variables (with the advantage that you don't need 'eval'
> to handle arbitrary values of 'foo'), then perhaps it's not unreasonable to
> expect [[ -v 1 ]] t
On 12/27/18 7:24 PM, Peng Yu wrote:
>> I don't believe that at all. The number of positional parameters is kept
>> anyway. It's not recalculated when you compare it to another number, so
>> it's just as fast as a simple comparison of two integers.
>
> Getting the number $# is slow.
You haven't pr
> A profiler is exactly what you need here. You should profile your
> script and understand the stuff that actually matters for your goals.
> Otherwise you're just chasing unimportant things.
Again, my goal is not to profile a specific bash script. The goal is
to see what features make bash only f
On Thu, Dec 27, 2018 at 08:57:12PM -0500, G. Branden Robinson wrote:
> What is it you're trying to achieve? State your goal in terms that are
> "SMART":
>
> (S)pecific
> (M)easurable
> (A)ttainable
> (R)easonable
> (T)imely
For the record, I tried for approximately two years to get Peng Yu
to st
On Sun, Dec 16, 2018 at 6:41 AM Eduardo Bustamante wrote:
:
> You know no one is stopping you from submitting a patch to actually
> fix the documentation right? (or maybe, you know, submitting an actual
> working patch to change the random generator, not just drop some
> irrelevant code snippet yo
13 matches
Mail list logo
