Article:		Excerpt from Linux Cookbook, Part 1
Subject:		Some Corrections
Date:		2004-12-09 23:44:29
From:		shlomif
The -v option for grep does not "turn on verbosity". What it does is invert the match and only display things that don't match. -e '^' does not mean exclude the following directory. It specifies a pattern to match, that happen to match at the beginning of the line (hence the "^"). Several -e's specify several patterns. In regards, to the solution proposed for 4.3, it is pretty brain-dead. Scanning the entire file-system twice is going to take a long time if it is very crowded. Furthermore, if something else is done there (like a cron-job or a different user handling his files), it may have some false positives. Generally, what I do to install programs, is either install from RPM (or .DEB or whatever), or use autoconf's --prefix option to install everything under its own directory. "slay" is interesting. "keychain" is also interesting.

Showing messages 1 through 5 of 5.

• Some Corrections
  2006-05-27 07:09:30  robhogg [View]
  
  

  What has not been commented on in the follow-ups to shlomif's post, is the (absoloutely correct) point that the explanations given for the flags used with grep are erroneous and misleading. This is especially serious in a book aimed at people who are not veryexperienced with Linux.

  
  
  

  I am surprised not only that it slipped past the proofreaders but that O'Reilly have this on their website to promote the book. I had been thinking of getting it, but seeing such a sloppy error has made me reconsider.

• Some Corrections
  2005-01-13 10:52:46  SlowBurn [View]
  
  
  Did you read the preface in the book. It isn't really meant for advanced users, but people new to the OS. While the methods describe are not the most optimal, they are easy to follow and understand.
  
  I think that is the point of it really. Once the reader has built a base of understanding they can dig out the most optimal way to do something and comprehend what it is that they are doing and why.

• Some Corrections
  2004-12-10 10:10:43  Fred_Arnold [View]
  
  
  "Brain dead"? No it isn't. I use almost the same method for generating file lists for source installs, because many makefiles do not include an "uninstall" target, so it saves a lot of time when I want to remove a program. I also exclude mounted network shares. Sometimes I will install everything in a single directory using the --prefix option for ./configure, for an application that I know I'm probably going to test and remove, but that presents its own problems- like program documentation that assumes certain file locations, so you have to spend more time making sure config files and commands reflect the correct filepaths. And it puts files in illogical locations, instead of config files in /etc, logfiles in /var, and so forth.
  
  Package installs really don't pertain to source installs. :)
• Some Corrections
  2004-12-26 02:57:38  trb [View]
  
  
  In most cases 'make install DESTDIR=/some/dir' is really the best way to do this. Once you make your list (find /some/dir | sed 's!^/some/dir!!' > file-list), you just 'make install' again and everything goes where it's really supposed to. No muss, no fuss.
  
  In cases where that doesn't work I can think of all kinds of suboptimal-but-still-better ways to do it besides finding and grepping (twice!) the whole file system, including using a union mount to direct all the newly-installed files to a scratch filesystem or doing one build with './configure --prefix' set to a scratch directory to make your list and then building the package again without the (or with a different) --prefix option.
  
  There are so many ways of doing this that are quicker, easier, and work better, that I think "brain dead" is a pretty good label in this case.
  
  Ultimately, of course, if your OS uses package management, it's smarter to just build your own packages and let the helper scripts/apps worry about making a file list. Package management eases system maintenance and upgrading by a huge margin, especially when you have to manage multiple systems.
  
  Plus in the case of distros like Gentoo and Red Hat (and just about everything else), where you have things like .spec and .ebuild files that script your build process, you're essentially documenting how to build the package while you're actually doing it, forcing you to take a step you should be taking anyway to make upgrading to future versions of the same software as painless as possible.
• Some Corrections
  2004-12-11 17:51:15  oisinfeeley [View]
  
  
  Package installs really don't pertain to source installs. :)
  

  If the system that you're working on has package-management then it would be easier in the long run to use that system. It's possible to take source files and make your own debs or rpms. This make upgrading, removing etc _much_ easier.

  
  
  

  It's definitely going to be quicker than doing a find, outputing a list, then diffing the list.

  
  
  

  Brain-dead may be a harsh description, so let's call it "sub-optimal" instead.