Showing posts with label post. Show all posts
Showing posts with label post. Show all posts

Wednesday, March 4, 2009

Using CSS To Wrap Your Pre-Formatted Blogger Text

Hey There,

Today's post is going to be a bit short, by which I mean that it's not going to be long. Of course, it also won't be short in the sense that it won't be abrupt and rude.

See ya,





Just kidding... ;)

I spent most of the time I had to come up with something to write about today, driving myself nuts trying to figure out how I could make this blog's code examples and block-quotes work in IE, FireFox and Opera; not to mention all of the other browsers out there. I don't think I'll ever be able to get the code examples to properly indent on Lynx, but at least it's readable now.

Even as I worked on that issue, I had this nagging feeling that I was going to have to go back and re-tag all 520 odd posts we've already put out, like I had to with our follow up on the absorption of knowledge in the computer age, which was the first post we'd ever done where the entire post had to look like a letter when seen from a bird's eye view. So, that was a bummer.

I started noticing that pretty much every forum I visited was filled with nothing but useless flaming. Guys who had the same question as I did, but were answered with some variation of "Why would you want your lines to wrap if you've already pre-formatted your text?" after which non-solution after non-solution would be offered up to not-answer the question ;)

Of course, there are some good reasons to want to be able to word-wrap your pre-formatted text. For instance, in this blog, we put up code from time to time. Sometimes a lot, sometimes none. But when we do put up code, we wrap it in the <pre> tags to preserve the indentation. This might not be necessary, but there's only so much leeway you have on Blogger. You have to use the tools they give you. No use putting in format tags that they don't honour. So, anyone can see that a loop within a loop within a conditional, with tabbed indents, can move the code out pretty far from the left-hand margin. So, if one of the triple-indented lines contains a good amount of text, I'd want that text to wrap around (just like it would in a standard terminal editor) instead of disappearing off under the right-side column.

Anyway, this post ends with good news that's both succinct and helpful (especially if you publish code on Blogger, too). All you actually need to do is add a "post pre" section to the CSS style section of your Blogger template. The beauty of this solution is that, not only does it work on all three of the aforementioned browsers, but it also fixed all of our previous code posts in one fell swoop :)

The code itself is here, you can add it anywhere in the:

/* Posts
-----------------------------------------------
*/


section. The CSS code is directly below, and the "post pre" container may not exist in the template you're using, just as it didn't in mine:

.post pre {
white-space: pre-wrap; /* This is for IE and other browsers that just have to be different */
white-space: -moz-pre-wrap; /* This is for FireFox and Mozilla Browsers */
white-space: o-pre-wrap; /* This is for Opera */
}


And, just like that, 500 or so wrongs have been righted. We'll be back tomorrow after we're all done being excited :)

, 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.

Monday, January 19, 2009

Extracting Different File Types On Linux And Unix - Guest Post

Hey there, everyone, hope you had a pleasant weekend :)

Today's Unix/Linux post is courtesy of TuxHelper and deals with the extraction of various types of compressed files in the bash shell. More specifically, it deals with setting up a very clever function that you can include in your .bashrc.

This little function is brilliant, in that it's so simple, obvious, and convenient that I can't believe I never thought to do it myself (I must be a glutton for punishment ;)

Hope you enjoy it and can "extract" some value from it (I really had to "push" that one ;)

Cheers, (and if anyone else out there would like to submit content and help me stave off that impending nervous collapse, please feel free to send me a comment :)





Thanks to "plb" on the debian forum for providing the tip/trick!

Open your .bashrc file located in your /home/$USER/ directory. It is a hidden file as some like to call it in the Gnu/Linux world. Assuming you have opened your file find a spot to paste in the following text:


function extract()
{
if [ -f "$1" ] ; then
case "$1" in
*.tar.bz2) tar xjf "$1" ;;
*.tar.gz) tar xzf "$1" ;;
*.tar.Z) tar xzf "$1" ;;
*.bz2) bunzip2 "$1" ;;
*.rar) unrar x "$1" ;;
*.gz) gunzip "$1" ;;
*.jar) unzip "$1" ;;
*.tar) tar xf "$1" ;;
*.tbz2) tar xjf "$1" ;;
*.tgz) tar xzf "$1" ;;
*.zip) unzip "$1" ;;
*.Z) uncompress "$1" ;;
*) echo "'$1' cannot be extracted." ;;
esac
else
echo "'$1' is not a file."
fi
}


Now go to your editor/notepad menu and save. The next time you have an archived file that need to be opened open a terminal/console and type: (example): extract myfile.zip!





, Mike



Yannis Tsopokis had this to add - Turns out this is all a lot easier than I ever thought. I'm officially a dinosaur ;)


For Linux there is unp which chooses which utility will extract the file and calls it.

Yannis

A huge supporter of the Rox Desktop had this to add - perhaps now, the correct source will get proper attribution!


This is actually from http://roscidus.com/desktop/Archive

tgz = Extract('tgz', "gunzip -c - | tar xf -")
tbz = Extract('tar.bz2', "bunzip2 -c - | tar xf -")
tarz = Extract('tar.Z', "uncompress -c - | tar xf -")
rar = Extract('rar', "unrar x '%s'")
ace = Extract('ace', "unace x '%s'")
tar = Extract('tar', "tar xf -")
rpm = Extract('rpm', "rpm2cpio - | cpio -id --quiet")
cpio = Extract('cpio', "cpio -id --quiet")
deb = Extract('deb', "ar x '%s'")
zip = Extract('zip', "unzip -q '%s'")
jar = Extract('jar', "unzip -q '%s'")

Justin Li noted this very important point! Thanks for contributing, Justin!


Hi Mike,

I have been a follower of the Menagerie for a while; your posts have taught me quite useful things. For the extract script though, wouldn't it be better if the script used file to find the filetype instead of matching against the file name? Especially since in Linux the file extension is only a convention for humans, the output of file would be much more accurate.

Keep writing about Linux!

Justin


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.

Thursday, October 2, 2008

Linux Vs. Unix: The Sins Of The Father?

Hey There,

If you're a regular reader ( or even a slightly irregular reader ) of this blog, you may have noted that from time to time I'll, tongue in cheek, make reference to, one day, eventually writing a post that basically says nothing, goes nowhere and ends flat, leaving you feeling like you bought another pet rock. For some reason, there is overwhelming interest in my actually going through with this and making a complete mockery of my blog (although I've felt, at some times, that I was achieving that end quite admirably ;) by writing just such a post. Since I pride myself, somewhat, in doing what I say I'm going to do (no matter how stupid or harmful ;) today has become the day that I put digits to keyboard and hammer out that post.

PLEASE NOTE: I'm not kidding. While this post may be somewhat amusing, you will probably walk away, after reading it, realizing only that you'll never ever get that time back. Without further ado, fanfare and/or circumstantial pomp, here comes that post. Please Stop Reading Now if you don't want to read a few paragraphs that will ultimately pose no problem, resolve nothing and leave without paying the check. You've been notified. This post is meaningless. It will also be written without emoticons from this point on. The whole thing's a joke. I just can't type that many winks in one post. The last time I attempted to, my keyboard got conjunctivitis and I had to have it deloused at the Rustler Steak House down the street from my Pet Psychic's favorite Organic Food outlet.

Unix and Linux are two keywords I like to use a lot in post bodies, and post titles, for this blog. It goes mainly to the fact that this blog is about lots of things Unix and Linux related. And, since it's next to impossible to do good SEO with a blog where the content on the front page changes entirely every day, falling back on those two words (and a few choice other ones) helps keep this cyber-rag in Google's goggles. You may have noticed that I used them in my title today and have, thus far, used the words Linux and Unix a total of 6 times (3 each) within a relatively brief chunk of text. I have no sense of direction and also can't calculate keyword density on the fly, but, if my offhand calculations are correct, I'd say we're looking at about a 100% saturation level, at the very most.

I'm a huge fan of Solaris and RedHat, which makes it hard for me to talk to plants, even though my wife insists that they're listening and I may actually be helping them grow. Still, when it comes down to a choice between using either Linux or Unix to complete a particular task, I tend to lean toward the wall in the office with the most stable furniture. I've been studying Feng Shui for some time now, and I can honestly tell you that nothing is where it's supposed to be. One of the underlying principles of that ancient practice (or is it just the only philosophy that involves heavy lifting?) is the assertion that where you put things can have a dramatic impact on your quality of life. For instance, if you stick a fork in your eye, you will be blind, bleeding, in severe pain and making a mess of your living area in no time. Luckily, the color red attracts good energy. The kind that will help you muster up the strength to either pull that fork back out of your eye or, at the very least, put your @ss in a car that (depending upon the severity of your wound) is either going to end up in the emergency room parking lot or wrapped around a tree on your neighbors lawn. If you release enough good energy, you may even attract the attention of strangers who will call 911 as soon as they've run out of video tape.

Fortunately, the solution to every problem is almost as simple as the problem itself. All you need to do is follow these 3 simple steps, and you'll be able to troubleshoot any Linux or Unix problem that comes your way. This is a tried-and-true method that is virtually 100% guaranteed...

1. Be sure that you understand the language in which the problem is being described to you. More pointless meetings have been adjourned due to poor communication than for any other reason. Understanding is key when you're dealing with someone who is completely paralyzed by irrational fear. If, after exhausting all options, you find that you still cannot make any headway, pretend to understand. Nodding, squeezing of the chin between thumb and forefinger and vague (yet distant) rolling of the eyes, coupled with comforting sounds like mmm-hmmm, can go a long way toward getting you to step 2 as quickly as possible.

2. Email the only supervisor you have who, for some reason, refuses to answer direct questions via any recordable medium. While he (or she) can be extremely irritating under most circumstances, you have an ally in this management-type who will provide you with absolutely bullet-proof @ss-cover if anyone ever comes around asking questions. Just be sure you send the original email and keep multiple copies (at multiple locations) of the response requesting that you get together to discuss the issue in person at an off-site location.

3. Using the information you've barely gleaned, and the brush off you've cleanly pocketed, during the execution of steps 1 and 2, manufacture an incident that trumps both with respect to both immediacy and length-of-engagement. If you have to get to work on something "mission-critical" right away and you might be going at it for days, without sleep, so that your company can hang on to some hope of staunching the flow of imaginary life-blood-cash, your problem should be reassigned soon enough.

IMPORTANT NOTE REGARDING STEP 3: Be sure that your "emergency" requires you to be off-site (i.e. out of the office and, preferably, out of the data center. Shoot for a non-extradition country, if possible) in order to fix it. Maintain communication only via pay-phone. Never turn on your computer or your cell phone. Be sure that everyone understands that they "are" talking to you on your company cell's speaker-phone (even though they aren't) and use a public terminal at the library to occasionally bounce a mail through a VPN connected to your organization's backup network. Make sure you manually edit the headers just enough to make them confusing to a human and completely sensible to a mail agent. If you maintain frequency-silence by leaving your cell phone and computer off, you can avoid suspicion to a better degree. Even the more paranoid among your masters will be somewhat comforted by the fact that all the systems are bad "and" the GPS devices they've weighed you down with aren't indicating where in the world you are. If you own a car, take a bus. You probably have Tom-Tom in there or some form of LoJack. If at all possible, find a place in the mountains (near a National Park or Wildlife Preserve) to do your heavy troubleshooting, live off of berries and kill your own food. If you're reasonably intelligent, after a week or so, you'll never want to come back.

That being said, given Solaris' and RedHat's solid track records, I think you'll find that, utilizing a proper steam-powered vacuum cleaner, you can make almost any stain look worse. If you do nothing else for the rest of your life, constantly berate yourself for buying white carpets. And don't go easy on your self. Be really mean. You deserve every moment of the grief you're going to endure. What were you thinking? That'll teach you to use Linux, when Unix is a perfectly acceptable alternative OS that is also entirely biodegradable, so you can feel superior while you're busy raping and pillaging the environment in some other way.

It goes without saying that...

, Mike




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

Saturday, May 31, 2008

Looking At Formal Systems On Linux and Unix

Hey There,

For today's post, we're going to put out a brain-teaser that won't get solved (at least on this blog) until tomorrow. It's based on a formal system (which is basically a set of rules, with specific applications, used as a method to solve an equation or problem) invented by Emil Post back in the 1920's and is most commonly referred to as a "post production system."

This basic formal system was re-popularized by Douglas R. Hofstadter in his book Godel, Escher, Bach: An Eternal Golden Braid" when he introduced the concept to folks, who weren't especially crazy about such abstract notions, by way of a little puzzle.

For today's post, we're going to reproduce (paraphrased, of course) that puzzle and let you see if you can solve it (or, if you can prove that it can't be solved, which is a possibility).

For tomorrow's post, we'll be putting up a script for Linux or Unix that will make this whole process much easier and will give you the option to "attack" this problem as quickly or slowly as you prefer. While the script will relieve you of the pleasure of completing this mental exercise (if it's at all possible to complete), it will either get you to the answer very quickly or make you wonder how long it might possibly take to solve. Considering the ingredients, that may turn out to be a huge chunk of your time ;)

And here we go. I hope you enjoy this puzzle as much as I did:

We begin with an absolute. You are starting out with a single string (which is absolutely defined, within the context of this formal system and puzzle, as a set of characters in a specific order - e.g. MI is not the same as IM). That absolute (or starting point) is simply "MI." (Note that all punctuation marks are "not" parts of the strings ;)

Give the string "MI," your goal will be to convert that string into the string "MU." Please note that, although a string like MIMUIM is a valid member of the M I U formal system, given the starting string of MI, you will never be able to have an M anywhere but in the first position. Sadly, this does not make finding the answer easy ;)

There are 4, and only 4, rules in this formal system, and you can only correctly solve the puzzle by applying any and/or all of them, one at a time, for as long as it takes to get you to "MU."

Rule 1: If your string ends with an "I", you can add a "U" to the end of it.

Ex: MI can become MIU.

Rule 2: If you have a string of the form "Mx," you can change that to "Mxx." Note here that the variable x can refer to a string (not necessarily just one character) and that only the letters M, I and U will ever exist in any string you produce by application of these rules. x is simply meant to be used as a variable notation.

Ex: MI can become MII
MIU can become MIUIU


The one thing to remember about this rule is that, once you've picked your character, or string, you can only duplicate it once per invocation of the rule. For instance, this is not acceptable:

Ex: MIU cannot become MIUIUII (duplicating "IU" and then duplicating the "I" before the "U," after the "I." You could do the following, however, in a number of steps:
MIU can become MIIUIU (by duplicating the "I" first, and then duplicating the "IU" from the resultant string)

Rule 3: If the substring "III" appears in your string, you can replace "III" with "U," but you may not do the opposite:

Ex: MIII can become MU
Ex: MU cannot become MIII


Rule 4: If "UU" occurs within your string (at any point), you can remove it from the string:

Ex: MIUUI can become MII

Using these 4 "rules of production" (or "rules of inference") can you take your initial string "MI" and change it to "MU"? Also, if it's not possible, is that provable? And, if it is possible, what's the fastest way to do it?

Have fun trying to figure it out. If you already own the aforementioned book, you may know the solution already (it's hidden somewhere in the approximately 700+ pages). Sometimes, though, your individual path to the solution will teach you a lot more than you'd learn by being told the answer :)

Enjoy,

, Mike

Thursday, April 17, 2008

More Fun With Bash Networking

Greetings,

You may recall a post we did about a week or so ago on accessing the network directly with bash. Today's post is a bit of a follow up to that introduction, with some tips and clarification added for clarity and/or enjoyment ;)

1. The basic setup (this will be the only part revisited from our original post on bash networking. In order to get any of this started, you'll need to exec a file descriptor in bash. The file descriptor can, theoretically, be any number, but you should avoid 0, 1 and 2, as these are generally reserved by most Unix or Linux shells for standard input, standard output and standard error I/O. To exploit bash's "virtual" /dev/tcp filesystem (note that you can use /dev/udp as well; it just depends what you're planning on doing - if you wanted to interact with an old NIS server, you might "need" to use the udp protocol), the setup is simple enough. Assuming we wanted to use file descriptor 9 to hit a google web server on port 80, this is what we'd type on the command line:

host # exec 9<>/dev/tcp/www.google.com/80 <--- We've now connected to www.google.com.

2. The rest of it depends on what you want to do. The most basic operation would be to send information to the new file descriptor, read information from it and close it. Those three things can be done like this:

host # echo -e "GET /search?q=linux+unix+menagerie HTTP/1.0\n\n" >&9 <--- And now, we've requested a search page
host # while read line <&9
do
echo -n $line >&1
done
<--- Now, we read the HTML page that gets returned.
host # exec 9<&- <--- This closes the standard input for our new file descriptor
host # exec 9>&- <--- and this closes the standard output

3. Using HTTP 1.1 instead of 1.0. This is actually quite easily done (and you can do it through Telnet to port 80 on any given host, as well. Telnet will allow you to connect to any specified port on a host and interact with it. You just need to know what to type ;). It just requires a bit more typing on our part. Assuming we have the initial file descriptor set up, per step 1, we would do this to initiate an HTTP 1.1 connection and read from it.

host # echo -e "GET /search?q=linux+unix+menagerie HTTP/1.1" >&9 <--- Note the lack of the double carriage return. This isn't absolutely necessary, but if those returns are typed, they obviate the next line.
host # echo -e "Host: www.google.com\nConnection: close\n" >&9 <--- This line tells HTTP/1.1 that we want to close the connection once our query, or page request, completes. HTTP 1.1 will keep the connection open until it times out unless you do this, while HTTP 1.0 will close it immediately after you send one request.

And then you can go ahead and read the response and close the file descriptors in the same manner as above.

4. Implementing host headers. You may find that more and more web servers require "host headers" when you send them an HTTP 1.1 request. These, technically are only required for virtual hosting, but it's becoming more and more common for out-of-the-box webservers to run the main server as a virtual host. It's easy to send a request to our file descriptor in this manner, as well. We just need to modify it slightly.

host # echo -e "GET /search?q=linux+unix+menagerie HTTP/1.1\nhost: http://www.google.com\n\n" >&9

5. Sending a POST request rather than the standard GET. This again, is just a modification on the main method. All you need to tell the server is that you're performing a POST action and send it the POST data (This is basically how the folks in security check to see if they can mess with your cgi forms):

host # echo -e "POST /search?q=linux+unix+menagerie HTTP/1.1\n\nHere Are All My POST Variable=Value Pairs" >&9

6. Ignoring the header information when requesting an HTML page using bash networking through file descriptors. This is kind of "voodoo," but is almost 100% guaranteed to work. The first blank line you encounter when you read your response to the query you send to a web server is (almost) always the end of the header section. The header section includes varying information on web server type, version, age, etc, but isn't worth reading if you just want the web page back. You can avoid looking at it by running this after you make the initial GET request:

host # while read <&9
do
line=${response//$'\r'/}
if [ -z "$line" ]
then
break
fi
done


And then you can move on and continue reading from the file descriptor, and closing it, just like in step 2:

host # while read response <&9
do
echo -n $response >&1
done
exec 9<&-
exec 9>&-


7. What you get if you settle. Interestingly enough, bash's "virtual" tcp (or udp) filesystem defaults to connecting to a webserver. If you simply exec a new file descriptor without any arguments, the "virtual" /dev/tcp, and /dev/udp, file system is still created. It defaults to port 80 and the tcp protocol. In fact, the virtual file system "always" exists. Why? Because your shell automatically opens file descriptors 0, 1 and 2 when it initializes. So, basically, when you login, you've already got a path to the net :) How to use it meaningfully is another thing entirely, but you can do this right out of the gate, just after logging in:

host # echo -n "GET / HTTP/1.0\n\n" >/dev/tcp/www.google.com/80

although, thankfully, it doesn't work all that simply and involves serious risk.

Exec'ing an additional file descriptor is a better practice when doing this sort of thing, because you don't want to muck with the 3 basic ones. If you make a mistake on file descriptor 9, for example, it's no big deal if it gets disconnected or something else weird happens to it. If file descriptor 0 get whacked, you won't be able to type to the terminal, and if file descriptors 1 or 2 get destroyed, you won't be able to see some, or all, of the output the shell is sending to your terminal. In either case, you risk losing your connection to your terminal session entirely.

Again, you can use bash's "virtual" networking to connect to any port that already has a service listening on it. Unfortunately, as far as I know, at this time, there is no way to "initiate" (or bind to) a network port using this method and the bash shell (or any Unix or Linux shell, for that matter). If it ever becomes possible, I'll be sure to post about it, because it will open up a whole new can of worms for all of us ;)

Again, if you would like further basic explanation (and a sample script) regarding setting up bash's "virtual" network connections, see our previous post on bash file descriptor networking.

Cheers, and enjoy!

, Mike