Get your own Free Home PageSunday, August 19, 2001 9:53:13 PM More Tech Talk: the PATH There is no one true PATH; each of us has his own PATH, the one that is right for us. What's in a PATH? It's the list of directories that is searched when the shell, the command interpreter, has determined that the command we typed is not known internally. That is, it's not part of the shell (a built-in), it's not an alias, and it's not a function. As a last resort the shell searches the PATH, hoping to find an executable file whose name matches whatever we typed. The order of the list is important. Solaris has a /usr/bin/ps and a /usr/ucb/ps, and whichever one the shell finds first is the one it's going to execute. It can get pretty sticky about it, too, because once it finds a ps, it may remember where the ps was found to keep from searching the whole path over again. This is called a "tracked alias," and by the time you change your PATH from "PATH=/usr/ucb:/usr/bin" to "PATH=/usr/bin:/usr/ucb" it's already too late. To make the shell forget the alias you may have to exit and start a new shell. If that's a little too much for you, run a subshell (just run "bash" or "ksh" or whatever) and the tracked alias won't carry into the new shell's memory. OK, so what's the big deal, if we can distinguish between /usr/bin/ps and /usr/ucb/ps? Can't we just type the full path name for the command we intend? Yes, in this rare special case. Let's now think about the cc command. In Solaris cc is a shell script, /usr/ucb/cc, and if you don't have the Solaris optional compiler installed, it's going to complain. Complaints are not something you need when you're compiling code. If you installed gcc off the web, you may have it in /usr/local/bin, and if you installed gcc as part of the "Companion CD," you will find it in /opt/sfw/bin. Either way, you have a new PATH element, and it should come before /usr/ucb. Or, perhaps, you can just "mv /usr/ucb/cc /usr/ucb/cc.orig" and forget about it. Ultimately, the PATH issue will keep coming up. Sometimes I talk with programmers who are upset that their computers take five minutes to log them in. Yes, they are in networked environments, and there are servers on the network that provide them with compiler tools and other goodies necessary for their projects. Upon further investigation, it may turn out that their PATH includes searches for directories that no longer exist. Either the server that used to have the directories is out of commission, or someone on their team has moved the commands to a "more convenient" location. Either way, the long login is a result of network time-outs that must be honored, just in case the server does respond, and that hold up the execution of weird project-oriented commands the programmers have used in their .profile or .kshrc files. It's amazing how fast they get logged in when I move their .profile to .profile- and their .kshrc to .kshrc- -- it's like magic! Did you add an element to your PATH and discover your new commands have no manual pages? Oh, yes. There's another path, not the true path, called the MANPATH. The usual place for manual pages on the default Solaris system is /usr/share/man, but there are others. If you are using /usr/local/bin/gcc, for example, then there is probably a /usr/local/man that goes along with it. If you're using /opt/sfw/bin/gcc, then look for a manual page under /opt/sfw/man. Of course you don't need to keep track of all that. Just place, right under "PATH=/usr/bin:/opt/sfw/bin:/usr/ucb" the line "MANPATH=/opt/sfw/man:/usr/share/man" and be done with it. Until the next time you add an element to your PATH. But wait, there's more! Now that you know the PATH is not the one true PATH, but that there is also a MANPATH, you might wonder what other paths lie in your way. Funny you should ask. One detail that beginning programmers know little of, that trips them up, is the dynamic linker, ld. Unless you specify "-static" in your compiler options, you get a "dynamically linked executable." This code, while compact, does not stand alone. In order for it to run, it needs to be linked, at run time, to a library on the target system. Note well that this is on the target system, not the system that did the compile. "Enough already," you say, "tell me the path!" It's a variable called LD_LIBRARY_PATH, and it needs to be set in the application user's environment. The default LD_LIBRARY_PATH is /usr/lib, but if you compiled with gcc it probably needs to be explicitly expanded, for instance to "LD_LIBRARY_PATH=/usr/lib:/opt/sfw/lib" in order to have a usable application. Other gotchas are lurking in the bushes. If you're using lclint, for example, you'll need to set LARCH_PATH, something I haven't seen used by other development tools. Maybe using the assignment "LARCH_PATH=/usr/local/lib:/usr/lib" will appease the savage lclint beast. One last word on paths: Don't forget to export them! It doesn't do much good for man or lclint if the appropriate path doesn't carry into their environment. It will be just as if you hadn't set it in the first place.
Saturday, August 11, 2001 11:35:27 PM Technoweenie Time-out Two of the Swiss army knives of the system administrator's toolkit are "grep" and "find." Find is good for, well, finding files that meet certain criteria; one has to live with grep for a while to appreciate its power. Find has so many options it's almost a toolkit in itself. It has always been a good way to start a security audit, as most system administrators would immediately think of running find through the whole Unix directory tree looking for files owned by root: find / -user root -print Of course, this command can take a very long time, and it uses up cpu cycles like nobody's business. On second thought, sysadmins would probably be interested in files that would be owned by root and that would have changed in the last week: find / -user root -a -mtime -7 -print Or even, whose attributes have changed in the past week: find / -user root -a \( -mtime -7 -o -ctime -7 \) -print I think you can see where this is headed. It doesn't take long before system administrators begin to make up their own tools, built on find, implemented as aliases or functions. For instance, a handy thing to have would be a tool that searched down a directory tree, looking for files that contained a particular word or variable name. Here, rather than learning how to use ctags and running vi by hand to find the files, a sysadmin could make a tool that uses find and grep in concert: Find() { find . -type f -exec egrep -il $1 } I was in a customer support center one morning, when a call came in from a system administrator who couldn't remove all the files in a temporary directory. There were thousands of them! He tried using the shell expansion rm * and he got an error message from the shell: "too many arguments." What was he to do? I happened to know that in the version of Unix that he was using, the find command would read the directory itself, bypassing the shell's limits. I recommended he try find . -type f -exec rm {} \; He was impressed, and said with a complicated command like that, he knew he was talking to a true Unix person. FreeBSD and Linux users should note, the current caching behavior of find makes it sometimes do no better than the shell on this problem. (Twilight Zone theme music here.)
Wednesday, August 01, 2001 8:55:05 PM When a UNIX computer decides that things have gone so wrong that to do anything at all will just make things worse, it "panics." The operating system, the program that controls the hardware, just leaves a copy of itself on a disk somewhere for a programmer to analyze and figure out what went wrong. In computer terminology, the copy is called a core dump, and it's an image of what was in memory when the operating system panicked. I like to think of the core dump as the cold, dead body of an operating system waiting for autopsy (although Microsoft likes to call the core dump a Watson file, which has a much warmer connotation, invoking the image of Sherlock Holmes). I have found that some students panic in much the same way that the UNIX operating system does. As long as they're in the classroom, listening to a lecture and observing other students' questions and answers, everything is fine. Then when my attention turns to them, and I ask them a question, they freeze up! I can see the gears turning in their heads, as they try to decide whether they have an answer worthy of the question. Is it too complicated, is it too simple? Is it completely wrong? Suddenly what they know doesn't count, and everything they don't know comes to mind. They stare at me like a deer in headlights at night. That's panic. When I was in the Coast Guard I once read a news article of an oil derrick that collapsed in the North Sea. All the life rafts launched, and the British forces scoured the surface of the ocean for the survivors. All the life rafts were empty, there were no survivors, and there were no bodies. I thought, perhaps they all went down inside the oil derrick. I wondered why experienced riggers would not be able to get off the derrick in a hurry, and why they couldn't get to the rafts. A few years ago I decided that the problem was panic. If the riggers realized they were in a seriously life-threatening situation, if their world were turned on its side and suddenly flooding with cold stormy water, if they were in a completely surreal scene, they might have just "hung on for dear life," not moved, and drowned. I was in a cave near Charlottesville, Virginia once, with a group of amateur spelunkers. We were exploring an area that was completely underground, a long way from the cave mouth, in total darkness. The light from our carbide lamps was all we had to see where we were going. The cave had a stream running through it in places, and we had to cross between two rooms through a chasm where we needed to brace ourselves on the cave walls to keep from falling into the stream. We had no idea how deep the stream was, but we didn't want to get wet. When I was in the middle of the passage, I panicked. I thought that if I moved a leg I would slip and fall; if I moved an arm I would lose my balance and fall. It was all in my mind, and I froze as solid as a statue. I wasn't going to take any weight off my arms and legs. After a few minutes my fellow spelunkers realized I wasn't moving, and they recognized the situation. One friend reminded me that I had handled the chasm perfectly well enough to get into that spot. Another reminded me that my lamp would run out of carbide soon, and I'd be in a much worse position if we had to find our way out of the cave in the dark. I calmed down, took courage, and moved effortlessly to the other room. What does it take to succeed in a high-pressure, mission-critical, 24x7 environment? A calm mind is an absolute necessity. If you keep a level head and keep moving, you'll be able to do what it takes to keep your company's servers running. What does it take to succeed in a high-pressure, first-to-market, ground-breaking commercial software development environment? A calm mind is an absolute necessity. If you keep a level head and keep moving, you'll be able to deliver your software project on time.
Return to David's Home Page
Your comments are welcomed by David R. Dull,
ddull@netcom.com.
(C) Copyright 2001, by David R. Dull.
All Rights Reserved.
Get your own Free Home Page