On 9/5/14, 2:57 AM, bogun.dmit...@gmail.com wrote:
> This is more or less the way I am leaning. In the next version of bash,
> it
> will be possible to set a limit on the number of recursive source/. or
> eval
> calls at compile time. This will be accomplished by changing a define
2014-09-03 7:31 GMT-07:00 Chet Ramey :
> On 8/28/14, 2:02 PM, bogun.dmit...@gmail.com wrote:
> > IMHO any user action should not lead to SIGSEGV! I am not objecting
> against
> > recursive "sourse" itself. But when I got SIGSEGV from "bash", I have no
> > idea why this is happened. I have made rec
On 8/28/14, 2:02 PM, bogun.dmit...@gmail.com wrote:
> IMHO any user action should not lead to SIGSEGV! I am not objecting against
> recursive "sourse" itself. But when I got SIGSEGV from "bash", I have no
> idea why this is happened. I have made recursive "sourse" by mistake and
> spend a lot of ti
bogun.dmit...@gmail.com writes:
O... you have more serious bugs
Than fixing a segfault that occurs when the user is obviously doing
something stupid? Sure.
2014-08-28 15:44 GMT-07:00 Chris Down :
> bogun.dmit...@gmail.com writes:
>
>> And what for this mailing list? Don't answer, this have no any sense any
>> more.
>>
>
> This mailing list is for reporting bugs. So far nobody thinks that what
> you reported is a bug, so you would essentially be makin
bogun.dmit...@gmail.com writes:
And what for this mailing list? Don't answer, this have no any sense any
more.
This mailing list is for reporting bugs. So far nobody thinks that what
you reported is a bug, so you would essentially be making a feature
request. If you want to prioritise that, i
2014-08-28 15:32 GMT-07:00 Eric Blake :
> On 08/28/2014 04:11 PM, bogun.dmit...@gmail.com wrote:
> >> If gcc segfaults because it implements #include via recursion, and I
> >> wrote a recursion loop of #includes into my source, then I'd say the bug
> >> was mine, not gcc's. Just the same as if yo
On 08/28/2014 04:11 PM, bogun.dmit...@gmail.com wrote:
>> If gcc segfaults because it implements #include via recursion, and I
>> wrote a recursion loop of #includes into my source, then I'd say the bug
>> was mine, not gcc's. Just the same as if you write a recursion loop
>> into your bash progra
2014-08-28 15:11 GMT-07:00 Chris Down :
> bogun.dmit...@gmail.com writes:
>
>> Is it so heavy to check length of $BASH_SOURCE array?
>>
>
> Adding artificial barriers that don't actually solve the problem are
> "heavy" in terms of technical debt, even if not code.
>
Ok. Please remove FUNCNEST limi
bogun.dmit...@gmail.com writes:
Is it so heavy to check length of $BASH_SOURCE array?
Adding artificial barriers that don't actually solve the problem are
"heavy" in terms of technical debt, even if not code.
2014-08-28 14:57 GMT-07:00 Eric Blake :
> On 08/28/2014 03:50 PM, bogun.dmit...@gmail.com wrote:
> > Any action in my script should lead to SIGSEGV in interpreter! If I write
> > program on some compilable language, for example C, compile it and got
> > SIGSEGV - this is my problem. But in this ca
2014-08-28 14:43 GMT-07:00 Eric Blake :
> On 08/28/2014 03:00 PM, bogun.dmit...@gmail.com wrote:
> >>> Whey there is check on division by zero? We can predict this? - No. But
> >> we
> >>> can detect it... and we out nice, detailed error message.
> >>
> >> Actually, division by zero is fairly easy
On 08/28/2014 03:50 PM, bogun.dmit...@gmail.com wrote:
> Any action in my script should lead to SIGSEGV in interpreter! If I write
> program on some compilable language, for example C, compile it and got
> SIGSEGV - this is my problem. But in this case, my program executed by
> interpreter, and if
2014-08-28 13:59 GMT-07:00 Bob Proulx :
> bogun.dmit...@gmail.com wrote:
> > Eric Blake wrote:
> > > bogun.dmit...@gmail.com wrote:
> > > > IMHO any user action should not lead to SIGSEGV! I am not objecting
> against
> > > > recursive "sourse" itself. But when I got SIGSEGV from "bash", I
> have
On 08/28/2014 03:00 PM, bogun.dmit...@gmail.com wrote:
>>> Whey there is check on division by zero? We can predict this? - No. But
>> we
>>> can detect it... and we out nice, detailed error message.
>>
>> Actually, division by zero is fairly easy to check, and this is probably
>> a case where bash
2014-08-28 12:08 GMT-07:00 Eric Blake :
> On 08/28/2014 12:49 PM, bogun.dmit...@gmail.com wrote:
>
> > If follow this logic - we shoul try to catch incorrect user behaviour...
> we
> > will got errors/signals from kernel.
> >
> > Simple situation:
> > $ ((1/0))
> > bash: ((: 1/0: division by 0 (er
bogun.dmit...@gmail.com wrote:
> Eric Blake wrote:
> > bogun.dmit...@gmail.com wrote:
> > > IMHO any user action should not lead to SIGSEGV! I am not objecting
> > > against
> > > recursive "sourse" itself. But when I got SIGSEGV from "bash", I have no
> > > idea why this is happened. I have made
2014-08-28 11:54 GMT-07:00 Greg Wooledge :
> On Thu, Aug 28, 2014 at 11:49:02AM -0700, bogun.dmit...@gmail.com wrote:
> > So why I should got SIGSEGV instead of nice, detailed error message in
> > recursion? We can detect it?
>
> You can't detect that it's going to happen. You can only receive th
On 08/28/2014 12:49 PM, bogun.dmit...@gmail.com wrote:
> If follow this logic - we shoul try to catch incorrect user behaviour... we
> will got errors/signals from kernel.
>
> Simple situation:
> $ ((1/0))
> bash: ((: 1/0: division by 0 (error token is "0")
>
> Whey there is check on division by
On Thu, Aug 28, 2014 at 11:49:02AM -0700, bogun.dmit...@gmail.com wrote:
> So why I should got SIGSEGV instead of nice, detailed error message in
> recursion? We can detect it?
You can't detect that it's going to happen. You can only receive the
SIGSEGV *after* it happens.
We already have a conf
2014-08-28 11:30 GMT-07:00 Eric Blake :
> On 08/28/2014 12:02 PM, bogun.dmit...@gmail.com wrote:
> > IMHO any user action should not lead to SIGSEGV! I am not objecting
> against
> > recursive "sourse" itself. But when I got SIGSEGV from "bash", I have no
> > idea why this is happened. I have made
On 08/28/2014 12:02 PM, bogun.dmit...@gmail.com wrote:
> IMHO any user action should not lead to SIGSEGV! I am not objecting against
> recursive "sourse" itself. But when I got SIGSEGV from "bash", I have no
> idea why this is happened. I have made recursive "sourse" by mistake and
> spend a lot of
IMHO any user action should not lead to SIGSEGV! I am not objecting against
recursive "sourse" itself. But when I got SIGSEGV from "bash", I have no
idea why this is happened. I have made recursive "sourse" by mistake and
spend a lot of time looking up what exactly lead to SIGSEGV.
Put a configura
On 08/27/2014 07:07 PM, bogun.dmit...@gmail.com wrote:
>
> Expected result:
> Block "source" for files already listed in "${BASH_SOURCE}". Perhaps this
> behavior and "changed" behavior should be switched by option in "set"
> command.
No. Recursive sourcing is useful, don't prohibit it artificia
On Aug 28, 2014, at 12:37 PM, Chris Down wrote:
> I really don't understand -- why is this unexpected? It's exactly what I'd
> expect to happen if you try to do something like that. It should not be
> disallowed to source yourself, that prevents people from doing things when
> *sensibly* sourc
I really don't understand -- why is this unexpected? It's exactly what
I'd expect to happen if you try to do something like that. It should not
be disallowed to source yourself, that prevents people from doing things
when *sensibly* sourcing their own script.
26 matches
Mail list logo
