Bug 1274553 - FUNCNEST is ignored if passed by environment
FUNCNEST is ignored if passed by environment
Product: Fedora
Classification: Fedora
Component: bash (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Siteshwar Vashisht
Fedora Extras Quality Assurance
: Reopened
Depends On:
  Show dependency treegraph
Reported: 2015-10-22 21:34 EDT by Alois Mahdal
Modified: 2017-02-20 14:07 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2017-02-11 02:40:47 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
infinitely recursing script (32 bytes, application/x-shellscript)
2015-10-22 21:37 EDT, Alois Mahdal
no flags Details

  None (edit)
Description Alois Mahdal 2015-10-22 21:34:37 EDT
Description of problem

If a script like this:

    # infinity.sh

    fn() {

is called, it will infinitely recurse, eventually hitting some limit and
causing SIGSEGV AKA segfault.  This is OK, as explained in bug 1118978
comment 14.

FUNCNEST variable (unset by default, allowing infinite recursion), can
be used to limit this and exit in a somewhat graceful way; following
script will not segfault:

    # noinfinity.sh


    fn() {

The problem is that calling the first version with FUNCNEST passed as
environment variable:

    $ FUNCNEST=10 ./infinity.sh


    $ export FUNCNEST=10
    $ ./infinity.sh

still leads to infinite recursion; IOW the FUNCNEST is set (you can
echo it anywhere in the script and see `10`) but does not really affect
the nesting.   Eventually the script will segfault just as if FUNCNEST
was unset.

Version-Release number of selected component


How reproducible


Steps to Reproduce

As described above

Actual results

FUNCNEST given via environment is ignored; unless the value is set in
script body itself it seems to be ignored.

Expected results

Running with FUNCNEST=10 or from environment where FUNCNEST is set to 10
(and marked for export where applicable), recursion should stop after
reaching the limit

Additional info

The current behavior does make sense, thoiugh:  Function nesting and
recursion is concept closely related to actual implementation within
the script, so indeed it does not seem very useful to pass that from

However, the variable scope should be clarified; current behavior is
confusing at least.  IOW, this may be just a documentation bug.
Comment 1 Alois Mahdal 2015-10-22 21:36:09 EDT
(In reply to Alois Mahdal from comment #0)
> Version-Release number of selected component
> ============================================
>  foo-2.2.7-22.el6.noarch


(sorry, forgot to replace version info in my template)
Comment 2 Alois Mahdal 2015-10-22 21:37 EDT
Created attachment 1085685 [details]
infinitely recursing script
Comment 3 Ondrej Oprala 2015-10-26 03:39:58 EDT
Hi Alois,
hmm you seem to be right, the variable is inherited, but the corresponding internal variable in the code is not set and I don't see any reason in the man page for that to happen. I'll ask upstream.
Comment 4 Fedora End Of Life 2015-11-04 10:18:50 EST
This message is a reminder that Fedora 21 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 21. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '21'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 21 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 6 Fedora End Of Life 2016-07-19 14:18:51 EDT
Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this

Thank you for reporting this bug and we are sorry it could not be fixed.
Comment 7 Alois Mahdal 2016-07-19 18:33:32 EDT
Still in F23.
Comment 8 Jan Kurik 2016-07-26 01:05:55 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 25 development cycle.
Changing version to '25'.
Comment 9 Alois Mahdal 2017-02-12 10:08:42 EST
So "Fedora vs. users" shows its ugly head again.  Bugs closed without even commenting about why, let alone getting them fixed.  Go on Fedora, frustrate away all your bug reporters!  Maybe one day, you'll be able to proudly claim "no bugs reported"!

I'm aware that Fedora is for free. I never complained that bugs don't get fixed *fast*.  But no, closing bugs without any explanation (bot or c/p texts with no relation to bugs themselves don't count as explanations) is just disrespectful, if not outright rude.

It's been 3 years since I started using Fedora and this has been constant source of frustration for me.  While I do know some Fedora maintainers and know that they do care about users, I feel like via Bugzilla, Fedora wants me to think otherwise.
Comment 10 Siteshwar Vashisht 2017-02-12 15:47:06 EST
bash was recently rebased to version 4.4 in rawhide and this bug is not reproducible with bash-4.4, hence I marked it as closed in rawhide. I believe the resolution makes it clear it was fixed in rawhide. Please reopen if you are still able to reproduce it on rawhide.
Comment 11 Alois Mahdal 2017-02-20 14:07:39 EST
I feel really silly now.  Siteshwar, please accept my apology for such heated (and very hasty and, as it is obvious now, so much incorrect) reaction.  I wish my previous comment just disappeared entirely.

Thank you for your patience.

(If Fedora ever frustrates me with closing bugs EOL, it has nothing to do with this bug!)

Note You need to log in before you can comment on or make changes to this bug.