• Not Again!?! Not that same old Unix trap.
I can't believe I fell into that trap again!
It's been over 12 years since I gave up being a full-time programmer (Fortran, C, assembly) to become a full-time tech writer (uh, sorry, Information Engineer). But I still play with C, Fortran, and some Java and PHP occasionally.
So last night I was testing out the new release of Sun Studio Express by creating a simple little C code that does numerical integration to compute pi. It's a textbook piece of code I've used before. So I copy/pasted the code into the editor window and saved it as sum.c, and built the object file sum.o and executable sum.
But when I attempted to run the program in a terminal shell, nothing happened. The program just sat there. No output, no exit, no prompt.
I checked the CPU monitor, nothing was running.
I checked and double checked the C code, the compile arguments, everything seemed ok. I even started removing statements. Still, nothing happened.
Then I ran it in the new GUI debugger, dbxtool. It ran perfectly, and exited as expected. What's going on?!?
I checked and double checked everything. Was I going mad? Have I been away from programming for too long? Am I getting old?! Is this programmer's Alzheimer's?
Nah, suddenly, out of the blue, it came to me.
rchrd% which sum
/usr/bin/sum
Of course! There's a command-line app called sum. It computes checksums! And, for security reasons (so they tell me), my $PATH variable is set with dot (.) at the end of the list, not at the front. (Actually, I should have run the local executable with ./sum -- generally a good rule to follow, but forgot, again!)
Solution: change the executable file to pi. Now it worked perfectly.
I had to laugh. How many times in my 30+ years with Unix have I been bitten by this one? Too many to admit to.
I guess one of the pitfalls of being an occasional programmer is that you tend to forget where the brambles are, and keep walking into that thicket over and over again.
( Nov 29 2008, 07:33:09 PM PST )
[Software]
Permalink
I have the same problem, but my pitfall is "test". test.c, compile and run... The problem with test on the other hand is that it's often a shell built-in, so looking at the PATH variable is not what makes me slam my forehead to the wall. It takes a little longer.
Posted by SwitchBL8 on November 30, 2008 at 03:50 AM PST #
The best way to remember to use "./sum" is to remove "." from your search path entirely. Then you'll quickly form the habit using ./foo to get to executables in the current directory. I made that change in college and have never looked back.
Posted by Chris Quenelle on November 30, 2008 at 02:14 PM PST #
Sounds like a good idea, Chris. Except now I'll get:
But still if I name the executable the same as a built in or standard CLI, I'm still hosed if I forget the "./"
I'll just add one more sticky note to the border of my screen and hope I remember to look at it again.
Thx.
Posted by rchrd on November 30, 2008 at 10:33 PM PST #
Ack! What I meant to say in sentence 1 was:
Sounds like a good idea, Chris.
Posted by Richard Friedman on November 30, 2008 at 10:58 PM PST #
Also, having . in your PATH is a security problem. How often do you cd to /tmp and then typo a command (e.g., 'xs' instead of 'cd')? on a multi-user system, where someone else could create an executable by that name in /tmp? Right, remove . from your PATH now.
Posted by Nico on December 15, 2008 at 05:46 PM PST #