title: Bash error “BASH_SOURCE[@]: unbound variable” including in a function call -why?
body: <p>NEQWIN= Why is <a href="http://www.gnu.org/software/bash/manual/html_node/Bash-Variables.html#index-BASH_005fSOURCE" rel="nofollow noreferrer">Bash variable BASH_SOURCE</a> sometimes unbound? Here's where I'm experiencing it:</p>
  
  <p>Months ago I designed &amp; defined these handy argumentless functions:</p>
  
  <pre><code>me_pushd_N78MKZ(){ #N78MKZ={NEQUFJ= pushd the current executing file's folder}
    pushd "$(dirname "${BASH_SOURCE[1]}")"&gt;/dev/null #N78MR4[enter link description here][2]=copy N6L19G; {based on http://www.gnu.org/software/bash/manual/html_node/Bash-Variables.html#index-BASH_005fSOURCE} {#N6W3XI="$0" gets the bash script name NOT this file if this file is sourced, as shown at N6W3KE, so replace with present.}
    };export -f me_pushd_N78MKZ
  me_popd_N78UN9(){ #N78UOX=undoes/closes me_pushd_N78MKZ
    popd &gt;/dev/null #N78UO9
    };export -f me_popd_N78UN9
  </code></pre>
  
  <p>-which are so useful they are at the start of my .bashrc as its very first code, as I am actually using as the next command my .bashrc: specifically I have is remainder code be essentially <code>me_pushd_N78MKZ; remainder_code; me_popd_N78UN9;</code> so then in remainder_code whenever I do a <code>source a_path</code> the a_path reference can be reliably relative --then <em>better-enabling me to break my .bashrc (and most any bash script) into included submodules so better manage it</em>. Calling this function pair also enabling easier (relative) path references for any script which needs to access multiple files (as my backup script bup.bak.N6KDW2.bash below)</p>
  
  <p>However now (&amp; seemingly only in the last few days), that <code>${BASH_SOURCE[1]}</code> is sometimes failing:</p>
  
  <ol>
  <li>with error <code>BASH_SOURCE[1]: unbound variable</code></li>
  <li>the same way on all Bash I've tried it on: just <a href="http://en.wikipedia.org/wiki/Cygwin" rel="nofollow noreferrer">Cygwin</a> 4.1.11(2)-release and (latest) 4.1.17(9)-release. I will eventually try it on Linux, but its not yet convenient to try it on Unixes including as it readily would require seting up several code files which haven't yet been setup for such portability as it hasn't yet been needed.</li>
  <li>NOT in my ~/.bashrc (that still works fine) but YES when placed in the ~/scripts/bup.bak.N6KDW2.bash I'm coding (which then begins <code>#!/bin/bash\n a_few_to_zero_seemingly_unimportant_commands\n  me_pushd_N78MKZ #NEQKEU=\n</code>), and YES the actual normal location of the me_pushd_N78MKZ call: .bak_set_N6RV5U.bash aka the configuration script which bup.bak.N6KDW2.bash sources.</li>
  <li>as well as when trying to access <code>${BASH_SOURCE[@]}</code> in that function (or another function called at the start of this script) as that variable is undefined, however very related {<code>${FUNCNAME[@]}</code> and <code>${BASH_LINENO[@]</code> each have proper &amp; multiple values.</li>
  </ol>
  
  <p><strong>So why &amp; when would <code>${BASH_SOURCE[@]}</code> be undefined? And why is it happening to me above?</strong></p>
  
  <ol>
  <li>The official docs, esp <a href="http://www.gnu.org/software/bash/manual/html_node/Bash-Variables.html#index-BASH_005fSOURCE" rel="nofollow noreferrer">for BASH_SOURCE</a> &amp; related, have no answer that I see.</li>
  <li>Still, I could imagine per its definition, where it gives the source file of a function, it might not be defined within a function call (although it seems it would there, too, as I see <code>${FUNCNAME[@]}</code> has as its last value <code>main</code>), however <em>I'm getting it SOMETIMES undefined within function calls with no clear pattern of when that I can see.</em></li>
  <li>So this would feel like a bug, but I recall it was working before, and the underlying code (Bash &amp; Cygwin) were not changed before I started getting this failure, I just change of my caller code (though can't remember what I last changed), so perhaps I've messed it up somehow or in some change stumbled upon a bug.</li>
  <li><a href="https://stackoverflow.com/questions/26823735/bash-error-bash-source-unbound-variable-including-in-a-function-call-why#comment-42219359">A respondent gives a possibility I can't well-evaluate “..in a SysV init system you have a prior executing instance of bash, where with systemd the init may be different..”</a></li>
  <li><a href="https://www.google.com/search?q=%22bash_source%22%20%22unbound%20variable%22" rel="nofollow noreferrer">Google Search("bash_source" "unbound+variable")</a> finds no answer nor related problem reports that I see on quick look, so <strong>I created this question foremost to gather others experiencing this or similar problems in hopes of <em>eventually</em> finding a solution</strong>, with further justification in next point:</li>
  <li>For those interested in the Q&amp;A process: since the problem {(1) fortunately <em>so far isn't causing me any showstoppers for me now and I haven't yet seen it enough to to know it would for me or anyone</em>, and (2) occurs amid considerable extra &amp; hard-to-isolate &amp; proprietary code files, and (3) occurs where what portion causing it I don't know (else I wouldn't be asking)}, as far as <a href="https://stackoverflow.com/help/mcve">site guideline MCVE</a> I've focused on still being Minimal but only as Complete &amp; Verifiable <em>as currently justified by the (this) need</em>, which, even if then few or perhaps no one can intentionally reproduce the bad behavior, is a report which can still be quite useful “to gather others experiencing this or similar problems in hopes of <em>eventually</em> finding a solution” quoting the previous point. So seems guideline MCVE should ideally be updated to note that its goals naturally should also be balanced with reporters' fix needs, as its goals very admirable indeed idealistic <em>but readily hard</em>. This update seems needed especially seeing there exist at least <a href="https://stackoverflow.com/questions/26823735/bash-error-bash-source-unbound-variable-including-in-a-function-call-why#comment-42233274">one user which this site's mechanisms rate VERY high (20K rep points, but somewhat mistakenly?) who mis-claims this Q as a severe “MCSE violation”, from apparently missing (else omitting) the need for this balance, and from definitely severely overly-criticizing on small &amp; personal &amp; useful aesthetics which were also already explained in next &amp; final point NEQWBQ</a>. Second, by the present MCVE guideline writeup, Complete's only goal is be complete <em>to “reproduce the problem”</em>, so to be Verifiable, so then Complete is better dropped as a top goal as Verifiable already implies it, so one would ideally just say “provide Minimal &amp; Verifiable Examples (MCEs)”.</li>
  </ol>
  
  <p>Thanks for any help.</p>
  
  <p>NEQWBQ=Aside: what are these codes as “NEQWBQ” on this paragraph? They're <a href="http://1.jothere.com/401?N46Ref=NEQWBQ" rel="nofollow noreferrer">short IDs to uniquely-reference, date-stamp, and portably-track most any point, item, or content</a>, including here I use to uniquely ID so track points, code lines, variables &amp; functions &amp; file names.</p>