Re: (OffTopic,) Gnu-Environment restrictions (was Re: Question )

2017-09-24 Thread Robert Elz 
I will send one more reply on this topic - I am replying to this message
as I agree with the change of Subject - this is off topic for this list,
which is why I will not respond any further to messages about this here.

Bob Proulx  said (in a message with the original subject):

  | Many people in the community have worked very hard to contribute to the
  | pool of free software.  People benefit from having this pool available.
  | I don't think it is bad to ask people using this pool of free software
  | to make derivations from it also available in the pool.

I don't disagree with that, and I don't think I said anything about good or
bad.

  | You can use the shared kitchen but please leave it in a better state than
  | you found it.

That would be fine, and would be free use.  But

You can use the shared kitchen provided that you leave it in
a better state than you found it.

is not.   It isn't necessarily unreasonable, but it is not free.

This, and the GPL, are just regular commercial transactions -- you give me
something, I give you something (that's called consideration in legal
circles, and just a promise to do, or not do, something, is sufficient).

While you (and perhaps even I, sometimes) might agree that the price is
reasonable, there is still a price, and software subject to the GPL is
not free.

L A Walsh  said:

  | Not really -- if one first examines the nature of 'freedom'.
  | I.e. what are we free to do?  Can we flap our arms and fly like
  | a bird?

You are confusing ability with freedom.   Now flying is a poor example in
any case, as even if I had the ability, at least in most jurisdictions,
I don't have the freedom, as flying is (mostly for good reason) a highly
restricted activity.   But that wasn't your point, if those restrictions
were not there (as they were not, a hundred years ago, or so, as back then
they didn't seen necessary...) then I would be free to fly, I just would
not be able to.

In the software world the same difference applies, there is much (truly)
free software that is available, which is useless to me, as I don't have
the ability to use it (and even more for which I lack the desire).  None
of that makes it any less free.

Calling something free, or not, relates to whether or not it is subject
to some restriction which limits its availability, and which is able
to be imposed or not, at the whim of whoever has the power in the
situation in guestion.

If something is free, then there is no such restriction, and all that
matters is my ability (or lack thereof) and desire (and similar.)
If it is not, then I need to negotiate with the relevant power source,
and enter into some agreement, by which they allow me to do what I want,
and I agree to do something for them in return.

  | The GNU license provides for a slightly modified reality
  | that allows for SW to be "free" under many conventional definitions,

If we are delving into altered realities, then I agree that almost
anything is possible, and in such a universe, any word can be defined to
mean whatever you want it to mean.   That's all fine, but is hardly helpful
when we are operating with the normal environment in which we all work.

kre

Re: Builtin echo interrupted by WINCH

2017-09-24 Thread Egmont Koblinger 
Hi,

Indeed, you're absolutely right. Reminder to myself: always test
latest devel version before reporting bugs :)

I've compiled devel with "make DEBUG= MALLOC_DEBUG=" and I could not
reproduce the issue with either of the commands.

Thanks a lot! :)

egmont


On Sun, Sep 24, 2017 at 7:48 PM, Chet Ramey  wrote:
> On 9/23/17 4:55 PM, Egmont Koblinger wrote:
>
>> Is there anything bash could do to prevent incorrect behavior of its
>> built-in commands when a SIGWINCH is encountered? And of course I
>> don't mean the "echo" command only.
>
> You can try, as the bash devel branch does, to install the SIGWINCH
> signal handler with the SA_RESTART flag. The readline code has always
> installed its SIGWINCH handler with SA_RESTART, but when it restores
> the bash SIGWINCH handler, it uses the flags bash uses, and until last
> December those didn't include SA_RESTART.
>
> --
> ``The lyf so short, the craft so long to lerne.'' - Chaucer
>  ``Ars longa, vita brevis'' - Hippocrates
> Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/

Re: [BUG] Bash segfaults on an infinitely recursive funcion (resend)

2017-09-24 Thread Chet Ramey 
On 9/24/17 1:53 PM, Shlomi Fish wrote:

> I see. Well, the general wisdom is that a program should not ever segfault, 
> but
> instead gracefully handle the error and exit. Perhaps implement a maximal
> recursion depth like zsh does. 

Perhaps read the documentation about the FUNCNEST variable. You get to
decide how much recursion you want.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/

Re: [BUG] Bash segfaults on an infinitely recursive funcion (resend)

2017-09-24 Thread Shlomi Fish 
Hi all,

On Sun, 24 Sep 2017 19:24:10 +0300
Pierre Gaston  wrote:

> On Sun, Sep 24, 2017 at 5:01 PM, Shlomi Fish  wrote:
> 
> > Hi all,
> >
> > With bash git master on Mageia v7 x86-64, bash on Debian Stable and other
> > reported sytems:
> >
> > shlomif@telaviv1:~$ /home/shlomif/apps/bash/bin/bash -c 'run() { run; } ;
> > run'
> > Segmentation fault (core dumped)
> > shlomif@telaviv1:~$
> >  
> 
> This, or some, variant has been reported multiple times.
> Like in most programming languages, you can easily write programs that
> behave badly,
> in this case you are exhausting the stack has there is no tail call
> optimization.
> 

I see. Well, the general wisdom is that a program should not ever segfault, but
instead gracefully handle the error and exit. Perhaps implement a maximal
recursion depth like zsh does. Also see the first item at
https://www.joelonsoftware.com/2007/02/19/seven-steps-to-remarkable-customer-service/
about permanently fixing reported problems at their core instead of dealing
with user reports and requests time and again.

Regards,

Shlomi

> see for instance
> https://lists.gnu.org/archive/html/bug-bash/2012-09/msg00073.html
> and the following discussion
> https://lists.gnu.org/archive/html/bug-bash/2012-10/threads.html#5



-- 
-
Shlomi Fish   http://www.shlomifish.org/
https://youtu.be/GoEn1YfYTBM - Tiffany Alvord - “Fall Together”

Chuck Norris does not keep any numbers on his mobile phone’s address book.
Instead, he memorised the entire phone directory.
— http://www.shlomifish.org/humour/bits/facts/Chuck-Norris/

Please reply to list if it's a mailing list post - http://shlom.in/reply .

Re: Builtin echo interrupted by WINCH

2017-09-24 Thread Chet Ramey 
On 9/23/17 4:55 PM, Egmont Koblinger wrote:

> Is there anything bash could do to prevent incorrect behavior of its
> built-in commands when a SIGWINCH is encountered? And of course I
> don't mean the "echo" command only.

You can try, as the bash devel branch does, to install the SIGWINCH
signal handler with the SA_RESTART flag. The readline code has always
installed its SIGWINCH handler with SA_RESTART, but when it restores
the bash SIGWINCH handler, it uses the flags bash uses, and until last
December those didn't include SA_RESTART.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/

Re: [BUG] Bash segfaults on an infinitely recursive funcion

2017-09-24 Thread Chet Ramey 
On 9/24/17 9:25 AM, Shlomi Fish wrote:
> Hi all,
> 
> With bash git master on Mageia v7 x86-64, bash on Debian Stable and other
> reported sytems:
> 
> shlomif@telaviv1:~$ /home/shlomif/apps/bash/bin/bash -c 'run() { run; } ; run'
> Segmentation fault (core dumped)
> shlomif@telaviv1:~$ 
> 
> note that this is not a fork bomb as no processes are spawned, and it is also
> not an out-of-memory problem. I expect bash to fail on this, but it ought not
> to segfault.

This has come up many times in the past.

You wrote a recursive function that eventually exceeds your shell's
stack space allocation, and the kernel sends it a SIGSEGV.

If you want to constrain function recursion, look at the FUNCNEST
shell variable.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/

Re: [BUG] Bash segfaults on an infinitely recursive funcion (resend)

2017-09-24 Thread Pierre Gaston 
On Sun, Sep 24, 2017 at 5:01 PM, Shlomi Fish  wrote:

> Hi all,
>
> With bash git master on Mageia v7 x86-64, bash on Debian Stable and other
> reported sytems:
>
> shlomif@telaviv1:~$ /home/shlomif/apps/bash/bin/bash -c 'run() { run; } ;
> run'
> Segmentation fault (core dumped)
> shlomif@telaviv1:~$
>

This, or some, variant has been reported multiple times.
Like in most programming languages, you can easily write programs that
behave badly,
in this case you are exhausting the stack has there is no tail call
optimization.

see for instance
https://lists.gnu.org/archive/html/bug-bash/2012-09/msg00073.html
and the following discussion
https://lists.gnu.org/archive/html/bug-bash/2012-10/threads.html#5

[BUG] Bash segfaults on an infinitely recursive funcion (resend)

2017-09-24 Thread Shlomi Fish 
Hi all,

With bash git master on Mageia v7 x86-64, bash on Debian Stable and other
reported sytems:

shlomif@telaviv1:~$ /home/shlomif/apps/bash/bin/bash -c 'run() { run; } ; run'
Segmentation fault (core dumped)
shlomif@telaviv1:~$ 

note that this is not a fork bomb as no processes are spawned, and it is also
not an out-of-memory problem. I expect bash to fail on this, but it ought not
to segfault.

also:

shlomif@telaviv1:~$ dash -c 'run() { run; } ; run'
Segmentation fault (core dumped)
shlomif@telaviv1:~$ zsh -c 'run() { run; } ; run'
run: maximum nested function level reached

I hereby put the reproducing code under the
https://creativecommons.org/choose/zero/ .

Credit is due to rosa, ongy, anEpiov and other people of freenode's
##programming channel for inspiring this bug report and helping to diagnose it.

Regards,

Shlomi

[BUG] Bash segfaults on an infinitely recursive funcion

2017-09-24 Thread Shlomi Fish 
Hi all,

With bash git master on Mageia v7 x86-64, bash on Debian Stable and other
reported sytems:

shlomif@telaviv1:~$ /home/shlomif/apps/bash/bin/bash -c 'run() { run; } ; run'
Segmentation fault (core dumped)
shlomif@telaviv1:~$ 

note that this is not a fork bomb as no processes are spawned, and it is also
not an out-of-memory problem. I expect bash to fail on this, but it ought not
to segfault.

also:

shlomif@telaviv1:~$ dash -c 'run() { run; } ; run'
Segmentation fault (core dumped)
shlomif@telaviv1:~$ zsh -c 'run() { run; } ; run'
run: maximum nested function level reached

I hereby put the reproducing code under the
https://creativecommons.org/choose/zero/ .

Credit is due to rosa, ongy, anEpiov and other people of freenode's
##programming channel for inspiring this bug report and helping to diagnose it.

Regards,

Shlomi
 m
-- 
-
Shlomi Fish   http://www.shlomifish.org/
Free (Creative Commons) Music Downloads, Reviews and more - http://jamendo.com/

For every A, Chuck Norris is both A and not-A.
Chuck Norris is freaking everything.
— http://www.shlomifish.org/humour/bits/facts/Chuck-Norris/