500 Unix/Linux Posts And Still Limping Tall!

Hey There,

Well, as the title of this post suggests (actually, asserts, unless it's toying with us ;) this marks our 500th post. Even though this is a momentous occasion (which most occassions composed of moments are ;) we're sticking to our guns and staying with the lazy (I mean diversified) format of the standard weekend post by showcasing other sites' humor :) It only took us 5 months of not analyzing any statistical data to realize that nobody liked to read about how to use Unix and/or Linux in the workplace on the weekends. That startling revelation led to our weekend-readership growing by about 500% (coincidence? The folks at Time-Life books would beg to disagree ;) If you didn't grow up in the 70's watching endless television commercials about American outlaws (amongst them, a bandit so ornery that he once shot a man just for snoring!) a lot of the in-jokes that litter almost every post like TP may seem like insanity. We assure, however, that (even if you did grow up at the same time we did) your perception is probably correct ;)

For our 500th post (which will, if our calculations are correct, make this our umpteenth weekend humor post), we bring you a message of worship to the ultimate text editor: ED! We found this piece in the Gnu Project's Mail Archives.

Since we'll be moving soon, anyway, we've come to the decision that we will no longer edit out profanity from our featured posts, at the risk of being labeled an "adult" site. This means that you can read the almost-exact-same thing at Gnu.org's page. Most of the stuff we've edited out over time has been fairly tame (in our opinion) anyway. Of course, the logical next steps (according to the Institute for the Preservation of Logical Fallacies ;) for this blog (after letting a "crap" or a "shit" slip through the cracks) are going to be drug humor (done it already) and pornography (haven't technically done it, yet, but just consider that everything is made up of 1's and 0's... Some folks somewhere have to find that entire concept sexually offensive (although statistics show that they're more likely to be offended if you wave a lot of 1's in their faces ;). If you're still single, avoid these people at all costs because - SPOILER ALERT - no matter how hard you try, you're not going to get laid ;).

The concept the whole progression, listed above, relies on is that you're too simple-minded to question authority. For instance, the use of swear words is a gateway to dehumanization and ever-increasing detachment from normal polite society (Which is just fuckin' crazy. Who "are" these meat puppets? ;). The same people who bring you that argument are also responsible for the world-famous "Marijuana is a gateway drug" argument; noting that most crack addicts started out smoking cigarettes and huffing joints. Of course, by that same logic, you could deduce that caffeine (found in coffee and most soft drinks) also leads to crack addiction. I'd bet my paycheck that a lot of those very same addicts started out with an innocent sip of Diet Pepsi or RC Cola. If they'd only known ;) You see what we mean, though, right? The backwards logic doesn't make sense unless you sensationalize it. Even then, it still doesn't make sense, but (if you're good at spinning public paranoia) by the point in time that anyone might come around to questioning the validity of your argument, you've pressed enough hot buttons in enough people to virtually ensure that anyone who has the courage to question you will be sought upon by an angry mob of delusional idiots ;)

As an aside, if you ever read the keyword lists for our weekend posts, do they sound like really poorly transcribed titles to Eastern TV or Movie comedies? (e.g. The happy funny laugh joke time show! ;)

As for keyword stuffing (think: Linux Unix Unix Linux Unix Linux Linux RedHat Solaris Perl Shell Script Perl Linux Unix Perl Shell RedHat SUSE Linux Bash Shell Linux RedHat Unix Linux Linux Linux Perl Unix Shell), we have yet to go there, but we may just give it a shot. This site doesn't really fare well in the SEO game, but that's never been our concern. Or, per our new editorial guidelines, we'd rather Linux write Unix helpful Redhat posts Shell on Unix topics Perl that Unix people Linux might Shell find SUSE useful Linux than Shell Script cow IBM tow Unix to Linux the RedHat arbitrary Linux whims Solaris of Unix whomever Linux is Perl in Unix charge Bash of Perl keeping Linux you Shell up-to-date Ubuntu with Linux what Unix you Shell should Linux enjoy Perl on Unix your Linux own Linux free Unix time :)

Enjoy this 500th post with our compliments (and derogatory gestures ;). It's some funny shit. Don't be afraid to laugh, even if the overt references to drug-induced sexuality and pornographic violence fuck with your head a little ;)

We'll see you at the "you must be 18 years or older" gateway page tomorrow!

Cheers,

---

Ed, man! !man ed

From: patl@athena.mit.edu (Patrick J. LoPresti)
Subject: The True Path (long)
Date: 11 Jul 91 03:17:31 GMT
Newsgroups: alt.religion.emacs,alt.slack

When I log into my Xenix system with my 110 baud teletype, both vi
*and* Emacs are just too damn slow. They print useless messages like,
'C-h for help' and '"foo" File is read only'. So I use the editor
that doesn't waste my VALUABLE time.

Ed, man! !man ed

ED(1) Unix Programmer's Manual ED(1)

NAME
ed - text editor

SYNOPSIS
ed [ - ] [ -x ] [ name ]
DESCRIPTION
Ed is the standard text editor.
---

Computer Scientists love ed, not just because it comes first
alphabetically, but because it's the standard. Everyone else loves ed
because it's ED!

"Ed is the standard text editor."

And ed doesn't waste space on my Timex Sinclair. Just look:

-rwxr-xr-x 1 root 24 Oct 29 1929 /bin/ed
-rwxr-xr-t 4 root 1310720 Jan 1 1970 /usr/ucb/vi
-rwxr-xr-x 1 root 5.89824e37 Oct 22 1990 /usr/bin/emacs

Of course, on the system *I* administrate, vi is symlinked to ed.
Emacs has been replaced by a shell script which 1) Generates a syslog
message at level LOG_EMERG; 2) reduces the user's disk quota by 100K;
and 3) RUNS ED!!!!!!

"Ed is the standard text editor."

Let's look at a typical novice's session with the mighty ed:

golem$ ed

?
help
?
?
?
quit
?
exit
?
bye
?
hello? 
?
eat flaming death
?
^C
?
^C
?
^D
?

---
Note the consistent user interface and error reportage. Ed is
generous enough to flag errors, yet prudent enough not to overwhelm
the novice with verbosity.

"Ed is the standard text editor."

Ed, the greatest WYGIWYG editor of all.

ED IS THE TRUE PATH TO NIRVANA! ED HAS BEEN THE CHOICE OF EDUCATED
AND IGNORANT ALIKE FOR CENTURIES! ED WILL NOT CORRUPT YOUR PRECIOUS
BODILY FLUIDS!! ED IS THE STANDARD TEXT EDITOR! ED MAKES THE SUN
SHINE AND THE BIRDS SING AND THE GRASS GREEN!!

When I use an editor, I don't want eight extra KILOBYTES of worthless
help screens and cursor positioning code! I just want an EDitor!!
Not a "viitor". Not a "emacsitor". Those aren't even WORDS!!!! ED!
ED! ED IS THE STANDARD!!!

TEXT EDITOR.

When IBM, in its ever-present omnipotence, needed to base their
"edlin" on a Unix standard, did they mimic vi? No. Emacs? Surely
you jest. They chose the most karmic editor of all. The standard.

Ed is for those who can *remember* what they are working on. If you
are an idiot, you should use Emacs. If you are an Emacs, you should
not be vi. If you use ED, you are on THE PATH TO REDEMPTION. THE
SO-CALLED "VISUAL" EDITORS HAVE BEEN PLACED HERE BY ED TO TEMPT THE
FAITHLESS. DO NOT GIVE IN!!! THE MIGHTY ED HAS SPOKEN!!!

?

---

, Mike

---

Discover the Free Ebook that shows you how to make 100% commissions on ClickBank!

---

Please note that this blog accepts comments via email only. See our Mission And Policy Statement for further details.

---

Easy Multiple File Patching And Patch Removal On Linux And Unix

Hello again,

Today we're going to continue with yesterday's post on manually mass patching files on Linux and Unix, but come at it from a different, and much simpler, angle.

First things first; you can delete the ed patch files from yesterday :) When you look at them, you can see that using "diff -e" to create an ed patch file creates a patch that contains absolutely no information that would allow you to reverse a change that you made, as opposed to a patch file made from diff straight-up. The small comparison below points this up more clearly:

host #diff -e tmpdir1/file1 tmpdir2/file1
5c
BASEDIR="/usr/binky"
.
host # diff tmpdir1/file1 tmpdir2/file1
5c5
< HOMEDIR="/usr/binky"
---
> BASEDIR="/usr/binky"

The ed patch file type that we used yesterday, although simpler to understand, doesn't make it possible to reverse your changes without keeping backup copies of your files.

The good news is that patch files created with diff can still be used to patch massive amounts of files and recover them even if the original, unpatched, files get lost or deleted. The method used to obtain these results is simpler than what we walked through yesterday and only requires the use of the "diff" and "patch" commands. Both of these commands should come standard with your OS. They've been on Linux for a long time and have been on Solaris Unix since, at least, release 2.6 (probably earlier).

So, let's get started patching lots of files and then backing out those patches. Since yesterday's post was so long (and this one has the same potential), I'm going to use only 2 files as the base number of files (although the number of files can be however large you want) and grep out the relevant information for display purposes. Hopefully it will save us all some eye strain ;)

The first thing we'll want to do is copy all the scripts we want to patch into a new directory to work on them. We'll also put the new scripts (that we'll need to create our diff patches) in yet another directory. We'll never work directly on the scripts in their native directory until we're sure they're patched correctly. This isn't absolutely necessary, but is generally good practice. No sense in letting a simple mistake cost you any more time, or grief, than it has to. Again, the only thing that is different between our existing scripts and the new scripts is that the HOMEDIR variable has been changed to BASEDIR.

host # cp scriptdir/* tmpdir1/

<--- This could be any number of files.

The following is our setup, with only one difference between the files, as noted above:

host # ls tmpdir1
.  ..  file1  file2
host # ls tmpdir2
.  ..  file1  file2
host # grep DIR tmpdir1/*
tmpdir1/file1:HOMEDIR="/usr/binky"
tmpdir1/file2:HOMEDIR="/usr/binky"
host # grep DIR tmpdir2/*
tmpdir2/file1:BASEDIR="/usr/binky"
tmpdir2/file2:BASEDIR="/usr/binky"

Next, we'll use diff to create a patch file. Although, rather than just doing diff straight-up, we're going to run it in "contextual" mode. When you invoke "diff -c" it creates a contextual diff which, literally, means that it puts the diff output in context (so you can see the lines before and after the lines that differ). The main reason I like to use this option is that the output works with "patch" when patching multiple files from multiple directories. The output from a standard diff of multiple files in multiple directories doesn't work well for this (mostly because it puts all the file names on one line and "patch" attempts to find a file named "diff tmpdir1/file tmpdir2/file" - literally. And that file can never exist (I hope ;)

Now we'll create the multiple file patch and examine its contents, created at the directory level directly above tmpdir1 and tmpdir2, so we can get all the files in both directories (Note that only the lines beginning with the exclamation point (!) in the diff output are different. The lines above and below only serve to showcase the line in its context within the file):

host # diff -c tmpdir1 tmpdir2  >patchfile.patch
host # cat patchfile.patch
diff -c tmpdir1/file1 vtmpdir2/file1
*** tmpdir1/file1     Wed Mar 26 14:36:05 2008
--- tmpdir2/file1     Wed Mar 26 14:54:10 2008
***************
*** 2,8 ****

  COMMAND_ARGS="-d --takeforeverandaday"

! HOMEDIR="/usr/binky"

  case $x in

--- 2,8 ----

  COMMAND_ARGS="-d --takeforeverandaday"

! BASEDIR="/usr/binky"

  case $x in

diff -c tmpdir1/file2 vtmpdir2/file2
*** tmpdir1/file2     Wed Mar 26 14:36:05 2008
--- tmpdir2/file2     Wed Mar 26 14:54:10 2008
***************
*** 2,8 ****

  COMMAND_ARGS="-d --takeforeverandaday"

! HOMEDIR="/usr/binky"

  case $x in

--- 2,8 ----

  COMMAND_ARGS="-d --takeforeverandaday"

! BASEDIR="/usr/binky"

  case $x in

Now we're ready to patch all of the files in tmpdir1 at once, using the simple form of the command (patch -i PATCHFILE), and receive an error for doing so. Note that we're running this from the directory above tmpdir1 and tmpdir2; exactly where we were when we used "diff -c" to create the patch file:

host # patch -i patchfile.patch
can't find file to patch at input line 4
Perhaps you should have used the -p or --strip option?
The text leading up to this was:
--------------------------
|diff -c tmpdir1/file1 tmpdir2/file1
|*** tmpdir1/file1    Wed Mar 26 14:36:05 2008
|--- tmpdir2/file1    Wed Mar 26 14:54:10 2008
--------------------------
File to patch: ^C 

<--- Type the control (ctl) key + C, or any other escape/control key combination to break out of this prompt

This error killed us before it actually made any changes because of the way "patch" works. When run without any options (other than -i, which we used to indicate the name of our patch file), "patch" parses the patch file and strips the file names down to the base, in much the same way the "basename" command does. So, even though the file name in the patch file is "tmpdir/file1," the "patch" program is looking for a file named "file1" and it's looking for it in the directory we're in which, unfortunately, isn't where the file is.

Luckily, this little setback is easy to remedy. Using the -p option to "patch" we can instruct "patch" how to interpret the file names in our patch file. As we noted, when the option isn't present, "patch" reverts to "basename" type behaviour. If we used -p1, we would be instructing "patch" to remove the leading slash (/) from the file name. We're going to use -p0, which instructs "patch" to not interpret the file name and just take it as it is (In this case "tmpdir/file1," which is relative, but just fine considering where we're running the command from).

host # patch -p0 -i patchfile.patch
patching file tmpdir1/file1
patching file tmpdir1/file2

Success! Now, let's check that the patch actually took:

host # grep DIR tmpdir1/*
tmpdir1/file1:BASEDIR="/usr/binky"
tmpdir1/file2:BASEDIR="/usr/binky"

Excellent! HOMEDIR is now BASEDIR. Alas, as I intimated in our post yesterday on mass file updating, our boss has, only minutes later, decided that the BASEDIR variable really should be HOMEDIR after all. He's not going to explain why, we just need to switch everything back now ;)

And this is where our method of execution really pays off. Assuming we held on to that patch file, we can now use "patch" to put everything back the way it was in short order, by simply adding the -R (to reverse the patch operations) to the command line and running it again, like so:

host # patch -p0 -R -i patchfile.patch
patching file tmpdir1/file1
patching file tmpdir1/file2

And, then, just to verify that the patch differences have been removed:

host # grep DIR tmpdir1/*
tmpdir1/file1:HOMEDIR="/usr/binky"
tmpdir1/file2:HOMEDIR="/usr/binky"

And we're all set :) Hopefully this follow-up tutorial was easy enough to follow, and you can find some good use for it in your work routine. BTW, don't forget to copy the changed scripts back to the real script directory, but only after copying that directory off somewhere else, again. But only if you're as paranoid as I am ;)

Best Wishes,

, Mike

linux unix internet technology

Manual Mass File Patching On Linux Or Unix

Good Day Good People :)

In previous posts we've looked at various aspects of the diff command, including augmenting it to generate unique content only and work with users, groups and permissions.

Today, I thought we'd look at diff's usage in a, generally, manual process and peek at the first step toward automation. Everything in this post can be scripted out to provide more granular control, and done much more easily. I thought doing it in a laborious tutorial style to start out with would be best to get the major parts of the process laid out simply and, hopefully, written in such a way that they're simply understood. After reading that last sentence, I'm wishing myself lots of luck ;)

For purposes of our example today, we're going to assume that we have a directory in which we keep 3 executable files. All of these files are approximately the same, because they all do approximately the same thing, just for different programs. For simplicity, they've been named: file1, file2 and file3, as shown in this directory listing:

host # ls
.  ..  file1  file2  file3

All of their contents are also almost totally identical:

host # cat file1 file2 file3
#!/bin/bash
# Start File1 Process

COMMAND_ARGS="-d --takeforeverandaday"

HOMEDIR="/usr/binky"

#!/bin/bash
# Start File2 Process

COMMAND_ARGS="-d --takeforeverandaday"

HOMEDIR="/usr/binky"

#!/bin/bash
# Start File3 Process

COMMAND_ARGS="-d --takeforeverandaday"

HOMEDIR="/usr/binky"

For today (and this would work if we had 5000 files, but this post is going to be long enough ;) all we need to do is change the HOMEDIR standard variable in all of our scripts to BASEDIR. I'm not exactly sure why. Someone with more authority than me or you decided it would be a good idea. They will probably change their mind and have us switch it back next week ;)

The first thing we should do is create a backup directory and do our work there.

host # mkdir ../u
host # cp file* ../u
host # cd ../u
host # ls
.  ..  file1  file2  file3

Then we'll just use a simple while loop and feed each file to sed and make the substitution, which we'll dump into another file called FILENAME.diff (So, file1 will get the substitution made on it by sed, and that difference will be put into a new file called file1.diff). Within that same loop, we'll be using the actual command "diff -e" to create an "ed" (A very basic Unix and Linux editor) patch file. Note that, for file1, this new file will be called file1.patch and that we echo a "w" and a "q" (on separate lines on purpose) into the bottom of the patch file.

host # ls -1d *|while read x;do sed s'/HOMEDIR=\"\(\/usr\/binky\)\"/BASEDIR=\"\1\"/' $x >$x.diff;diff -e $x $x.diff >$x.patch;echo w >>$x.patch;echo q >>$x.patch;done

We could have deleted our file*.diff files above, as well, but I thought you might like to take a look at them. These serve as proof that our sed command actually worked :) HOMEDIR is now BASEDIR!

host # cat file1.diff file2.diff file3.diff
#!/bin/bash
# Start File1 Process

COMMAND_ARGS="-d --takeforeverandaday"

BASEDIR="/usr/binky"

#!/bin/bash
# Start File2 Process

COMMAND_ARGS="-d --takeforeverandaday"

BASEDIR="/usr/binky"

#!/bin/bash
# Start File3 Process

COMMAND_ARGS="-d --takeforeverandaday"

BASEDIR="/usr/binky"

Now, let's delete the *.diff files and take a look at the patch files. These are all considered "ed" scripts. This means that we can feed them to the "ed" Linux/Unix editor and have it execute commands for us automatically. This will come in handy in a second :)

host # rm *.diff
host # cat file1.patch file2.patch file3.patch
5c                    <--- These first three
BASEDIR="/usr/binky"  <--- lines were created
.                     <--- by "diff -e"
w                     <--- We manually added
q                     <--- these last two!
5c
BASEDIR="/usr/binky"
.
w
q
5c
BASEDIR="/usr/binky"
.
w
q

The next step in the process is to apply those patches. We're going to be doing this all in our test directory, so there's no need to tar up all the patch files for a move to our "live" script directory

host # ls
.   file1        file2        file3
..  file1.patch  file2.patch  file3.patch

So, now we're ready to test our mass change and pray all goes well. Note that, since we're still in our backup directory, we can do lots of damage to the scripts in here and it shouldn't make a difference to anyone. Only we will have to live with the shame ;)

Now, we'll do another fancy command line and pipe the output of "ls -1d *", grepping out all the patch files and then using "ed" to patch each file in the directory. Notice that the syntax for patching a file with an "ed" diff script is "ed FILENAME <FILENAME.patch" - This would normally hang and wait for us to send it a control-D or some other signal, but, since we echoed the "w" and "q" characters into the patch files, "ed" knows to write (w) and quit (q) - At the end of the command pipe, we'll purposefully not delete all the patch files. You can remove them if you like, but we'll be looking at using them to undo changes in a future post!

host # ls -1d *|grep -v patch|while read x;do ed $x <$x.patch;done
107
107
107
107
107
107
host # ls
.   file1        file2        file3
..  file1.patch  file2.patch  file3.patch

Okay, we're all done and now we can check the results. Looks like everything in our (potentially huge amount of) files got patched appropriately :) This shouldn't be a surprise since we checked our sed output already, but you never know.

host # cat file1 file2 file3

#!/bin/bash
# Start File1 Process

COMMAND_ARGS="-d --takeforeverandaday"

BASEDIR="/usr/binky"

#!/bin/bash
# Start File2 Process

COMMAND_ARGS="-d --takeforeverandaday"

BASEDIR="/usr/binky"

#!/bin/bash
# Start File3 Process

COMMAND_ARGS="-d --takeforeverandaday"

BASEDIR="/usr/binky"

In a future post we'll look at a script that will allow us to do what we've just done today and make life a little easier when doing mass updates or patching :)

Cheers,

, Mike

linux unix internet technology