Path: csiph.com!xmission!news.snarked.org!news.linkpendium.com!news.linkpendium.com!panix!usenet.stanford.edu!not-for-mail From: Frank Edwards Newsgroups: gnu.bash.bug Subject: Re: declare(1) not executing inside source'd script Date: Fri, 27 Jul 2018 12:42:31 -0400 Lines: 83 Approved: bug-bash@gnu.org Message-ID: References: <20180727042606.EFCD8120EA6@student.eeconsulting.net> <20180727141701.rt26jd6vymkf6uwb@eeg.ccf.org> <31E3E1B2-208C-47BE-B5CF-F5C76D4F5DCE@eec.com> NNTP-Posting-Host: lists.gnu.org Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: usenet.stanford.edu 1532709792 9376 208.118.235.17 (27 Jul 2018 16:43:12 GMT) X-Complaints-To: action@cs.stanford.edu Cc: bug-bash@gnu.org To: Greg Wooledge Envelope-to: bug-bash@gnu.org In-Reply-To: <31E3E1B2-208C-47BE-B5CF-F5C76D4F5DCE@eec.com> X-Mailer: Apple Mail (2.3445.9.1) X-Provags-ID: V03:K1:JagURm7wxD5XoawBep7RuehrDaVe5dlm+Y5RoQjmgn2XkUrf1Ei 22kRUjrjQSQQwEYs/j6q4NB97lDpUIGrE83gznUwAq5PeqpTbEyixLLqU6wWV3k+oq/bx2y n92x3qLamuUNjPXvZBU2Xj3KYgW+94j7pxnY+P9i2zozNtslw0Nxu4GcKW+Id7eBE1iG2hY dpDgU3TW094Q8QCpNTsXQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:KIeG6QvnF00=:TaziUOoBK0gVraluF/rtgH DkgmJOiEYdEW6WOAArLJaQHld1zc8nRiFqOsAaSNMTWmr0ucdbEg4yydPZ4W898Tya4gNFr6C kltHmaMujG0fjjxxzJbFrpl6i5/QOd5owiWVfWYzmCbdSgFxm2zv8eWJXcWdTo6jU0FLSDZax BjIFRdD4nYR6od4K4lT7nhpzLZbS1LMWM+2I2pVNj3l6fc+MLiVA9c8QyFC/2381h9JcYTiZI NNpCwdEYcilPt7MXV9fbfch7OVB69s54t+i47J32ClThbI7YUKhw6O1QBskmAgiuvPJS+N2Gd YueXxVGflHHISiWXKnNSRXVtuul7VqHmi6wq+Szg9NdaA5xehyQzJtszMraZW5hVLR+tOd3+0 NN6R33yozdEL2dgJMoqq4CEqVhnJDFFSdZSuRsU/KYA7nBlDzJJQv3flTBXFHk7IXMWmVjnkO E/o2yKn/V7gno8I7kQhc7KuBRteyPr9cV9lX2bzEUeSebJ3+qI5CYVbezDqBp9Zs1EZzW85K8 zSVC3UbC7nyLXEMbkt4rWDf32o7pKpldRy+3GDFrIKxbyE1NaV3gbeFVoH3+ER1Q0OMuOTTuX sYSwfRgeXBKc1ljYGe/bZE6bf4CqQbO6jkW5XihbZT7kM2Gi43aVaikFRv0oeKFPN5v8DcrUZ IBM4TetZEdAUyxCzNqqrVHJliHjx+OCuQ2dP4jBLmLlFOtffaTaaF5S0x1jH+C6y73dX+/xkx tzWv04WbpI6Ydkj9 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 74.208.4.194 X-Content-Filtered-By: Mailman/MimeDel 2.1.21 X-BeenThere: bug-bash@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Bug reports for the GNU Bourne Again SHell List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Xref: csiph.com gnu.bash.bug:14413 Thanks for your help; I found the problem. It was a directory in my PATH that included another copy of the script = by the same name. I should have been using ./script_name when passing = it to the source command. I found this by placing set -x inside the = script to see what was going on and it never ran. The which command = didn=E2=80=99t help, but whereis tracked down the duplicate. Thanks again for your time (this was embarrassing, as I know better :)). =09 Edwards & Edwards Consulting, LLC Frank J. Edwards sales@eec.com Voice: +1 813.406.0604 (rings both office and mobile) > On Jul 27, 2018, at 11:28 AM, Frank wrote: >=20 > Hm. Strange. I will examine the environment for weirdness regarding = BASH_ENV or anything else that might be an issue. Given that it happens = for me in both the stock bash 4.2.46 and the locally built 4.4 (on = CentOS 7.4), there must be something common to both and thus external to = the shell itself. >=20 > I have installed bashdb on this system as well, but I don=E2=80=99t = expect that to have affected anything since it=E2=80=99s an add on that = Bash shouldn=E2=80=99t have noticed without the use of --debugger. >=20 > Thanks for your help. >=20 > PS: So the official line is to not specify the man section for = builtins to the shell? I will not use section numbers in the future. :) > -- > Frank Edwards > Edwards & Edwards Consulting, LLC > Hours: 10A-6P ET > Phone: (813) 406-0604 >=20 > Sent from my iPhone. No electrons were harmed in the creation or = transmission of this message. >=20 >> On Jul 27, 2018, at 10:17 AM, Greg Wooledge = wrote: >>=20 >>> On Fri, Jul 27, 2018 at 12:26:06AM -0400, frank@eec.com wrote: >>> Repeat-By: >>> $ cat <<__EOF__ >/tmp/bashbug.bash >>>> function myfunc { >>>> echo "Running..." >>>> } >>>> declare -fx myfunc >>>> declare -p -F | grep "myfunc" >>>> __EOF__ >>> $ source /tmp/bashbug.bash >>>=20 >>> The function is now defined, but is not exported. >>> And the output of the last command never appears, >>> but if the same command is executed now -- at >>> the interactive shell prompt -- it does show that >>> 'myfunc' is defined. >>=20 >> I cannot reproduce this, either in Debian's bash 4.4, or in bash = 5.0-alpha. >>=20 >> wooledg:~$ exec bash-5.0-alpha >> wooledg:~$ cat foo >> function myfunc { >> echo "Running" >> } >> declare -fx myfunc >> declare -p -F | grep myfunc >> wooledg:~$ source ./foo >> declare -fx myfunc >> wooledg:~$ bash -c myfunc >> Running >>=20 >> On my system, I see the output from "declare -p -F" upon sourcing the >> file, and the function is definitely exported. I get the same = results >> using Debian's bash 4.4(.12) as well. >=20