On Fri, Jun 22, 2001 at 02:15:12PM +0000, Iain Smith wrote: > > Until I found out about this wonderful "-r" option to gnu grep: > > > > grep -r myregex /etc > > > > wants to be your friend too. > > Hmmm.... I managed to miss that one completely. Time to re-rtfm! I knew of > rgrep but found it was rarely available in avg distros... I guess I know why > now!
Yes, rtfm is good. Good sysadmin books will not teach you how to be r00t in 24 hours, but instead tell you "stop reading here and only come back when you've read all of your system's manpages". :-) In my experience, the best one is the bash(1) manpage. It is is really vital. You don't properly realise how much until you've read all of it (well maybe read a little faster over the readline bits). Next come grep(1), sed(1) and awk(1). They come together quite naturally. These are one of the first unix tools and they are still around. Conceptual simplicity is the essence of their strength and the reason for why they're still around so much. Studying them is about more than these tools per se, it opens up a view on unix concepts and approaches. And that is the real gem to be won. Meanwhile you may be tempted into taking a little detour through regex(3) and printf(3) and maybe some others too, that would be okay. At this point I could start on perl and how it another example of a place that harbors the unix mindset, even though nowadays you can run it everywhere but on a nintendo. You can even run it on your (developer edition) playstation2 :-) I've heard perl being described as "Schaum's outline on unix" and there's a lot of truth in that if you ask me. But if you were to jump into the perl sea, I would not really expect you to ever come drifting back to that sysadmin book ever again. :-) Of course, all this is meaningless without the proper background. There's no escape to reading K&R C book, even though it might seem very little relevant from a distance. It is tremendously relevant, because all the basic unix stuff is built on it and largely in its spirit. Also must do is to read a book on unix systems. I suggest the 4.4 bsd book, because it is a lot more readable than some of the more well-known pamphlets by various illustruous academics[1]. Also, Kirk McKusick has a video with the book and you're missing out if you have not seen it. It is brilliant. I wish that some day, there will be something similar for linux and that it will have all the beautiful anectdotes that light up the McKusick tapes. This is really unix at its best: vibrant with culture. [1] Tanenbaum's "Structured computer organisation" otoh is very lucid, yet quite straightforward about the technical details aspect that is so inherent to the matter at hand. It also shows a good sense for anectdotal evidence and putting things in a bigger picture. in retrospect, maybe I should have put it before the C book, because you probably don't get all of C if architectural concepts are like magic to you. But in another sense it also a bit to far off course here. > > > rather than using cat, you'll get the names of any files containing > > > matches > > > back using this method. Also, it may be worth changing the search base to > > > / > > > as IIRC a search on a potato box turned up some matches elsewhere on the > > > filesystem... > > > > Watch out for all the rope hanging about in dark corners of /proc and > > /dev. Your point is valid though, but I doubt that you'll find > > much of importance outside of /var. And then most of what is in /var > > should probably change itself when daemons restart or should just stay > > like it was, like your archived logfiles. > > /proc and /dev? Shirley the next reboot would cure /proc... though admittedly > it's not always an option... and an all together too windowsish solution! ;) You really don't want to mess with /dev/kmem and /proc/kcore. Install and setup a user-mode-linux system if you like to toy with that stuff without exposing real data to real danger. Cheers, Joost
