It was about three o’clock on a Thursday afternoon when Kevin called me.
I remember the time because I had just been thinking about knocking off early. It had been a hard week, and the P&L was looking good, so I was ready for a break. Then my cell phone chimed, and when I pushed “Talk”, Kevin’s voice was in my ear.
Kevin doesn’t call me all that often. We hardly ever see each other socially any more- he’s in Seattle, I’m here on the East Coast. He’s a Filepro and C kind of guy, neither of which I do much with any more. We keep in touch; Xmas cards and all that, but only chat now and then, and usually it’s just that: chit chat.
But today Kevin had a problem. “I’ve got this script that keeps looping on itself and I can’t figure out why”.
Well, I knew better than to ask the obvious- Kevin is no fool: the script wouldn’t be calling itself. But I also knew that Kevin was doing more and more Linux, so I asked “What OS?”. The answer came across the country on fiber optic cables and was then broadcast for my cell phone to pick up: “Red Hat 6.1, patched to hell”.
I thought for a second and said “Let’s just try something- this isn’t your answer, but just humor me. Put “#!/bin/sh” at the top of your script”.
Kevin paused before he answered. He knows I’m not an idiot, but sometimes he wonders.. “Umm, sh is a link to bash on Linux”, he said.
“I know”, I explained, “but just do it anyway. Try it.”. I heard keys clicking, and then his voice came back. “Son of a gun- it doesn’t loop- I don’t get it. What’s going on?”.
It was my turn to pause. “Well, I have another question, though it’s really more of a statement: you have this script run when you log in, don’t you?”.
“Yes”.
“That’s the problem. You’ve done that wrong, and that’s why it is looping”.
Do you know what Kevin did wrong and why the “#!bin/sh” stopped the loop?
Answer
As we know, Kevin wanted his script to run when he logs in. If he had been running /bin/sh instead of bash, he would have called his script from .profile, but bash gives you more choices.
Bash prefers to find its startup in either .bash_profile or .bash_login. These two are interchangeable- bash will use either one- if it finds .bash_profile, it will use that, if it doesn’t, it will look for .bash_login. If it doesn’t find either, it will then look for .profile. So Kevin could have put his commands in any of these.
Instead, he put the line that called his script in .bashrc and that’s what caused all his problems. Bash will run .bashrc when you login, but it also runs it whenever a new bash shell is launched- which is just what happens when you run a script.
Try this on a Red Hat system (you won’t be able to duplicate this on a SCO system or even a BSD system- it seems to be specific to Linux):
Create a script in your home directory called “t”.
-==-
Now edit your .bashrc to add these lines:
-==-
-==-
until you interrupt with CTRL-C. Change the “t” script to:
-==-
and there will be no loop. That’s because even though /bin/sh is a link to /bin/bash, bash acts differently when it is called as sh: if it’s interactive it will ONLY look for .profile, and, interactive or not, it will never run .bashrc. The solution, of course, is not to put “#!/bin/sh” at the top of the script- the line that calls it should be taken out of .bashrc and put in .bash_profile. The .bashrc file should be used for variables and aliases that you want set to a known value when you run a script or start a new shell.
Originally appeared at http://www.aplawrence.com(http://www.aplawrence.com/Detective/shbash.html)
Please read this disclaimer
Copyright and Reprint Info
A.P. Lawrence provides SCO Unix and Linux consulting services http://www.pcunix.com
