What’s a Ball of Tar and a Zipper Have to do with My Linux Box?

Tarball files ( .tar ) are file archives commonly used in Linux and Unix file systems to store data backups and to assist in transferring of multiple files and directories quickly. Usually, tarbal ( .tar ) files are compressed with the GZIP library in order to save space, and make transferring quicker. Gzip’d tarball files are often have a .gz or .gzip file extension succeeding the .tar, and in equal are commonly used to backup and store data, as well as for transferring multiple files and directories around on the internet quickly and easily.

Why View the Contents of an Archive Without Extracting It?

There may be occasions when you simply want to see what is inside of a tar gzip file without having to actually extract the contents. This is Continue Reading

You wish you didn’t have to copy files and folders twice on your Linux web server, and consistently have to come up with a way to keep the duplicate files or directories synchronized?

A symbolic link in Linux or Unix is a virtual pointer to another directory or file. It acts in all ways as if it were the original file or folder. A symlink will appear in any directory listing (ls -al), and will indicate the original directory or file. All child directories of a symlink directory will inherit the symbolic link’s directory path when accessed through the symlink. Any changes made to the symbolically linked file or directory, will occur in the original actual file or directory, as the symbolic link just points straight to it. Continue Reading

So, you want to change the Linux permissions of all files in a directory and all sub directories, but not affect the permissions of the folders?

This simple guide will show you how to do a recursive chmod changing only the permissions of files, while leaving the permissions for all directories untouched.

The recursive chmod-files-only syntax:

The following shell command will chmod all files only (and ignore the directories) setting the permissions to 644. Continue Reading

Often times I’ve seen where people attempting to follow troubleshooting instructions from a technical support department run into problems with the instructions.  It may or may not always be the fault of the end user, but typically can be blamed on a lack of clear communication (or miscommunication).

Many times people fail to realize that the term “command prompt” loosely applies to two separate, but very similar utilities made by Microsoft;  “CMD” (cmd.exe) and “command” (command.bat).

“Command” is the depreciated and no longer officially supported command line interface utility for Microsoft Windows. It made it for the last time into Windows XP’s distribution, however has been dropped from any inclusion into future windows releases, including the current Windows Vista and the upcoming Windows 7 Seven.

As seen in the screenshot below, launching “command” from the Start > Run menu brings up the below window.

The first line of the command line interface states Microsoft(R) Windows DOS.

Microsoft Windows command.com Utility. Please note if you are using a Microsoft Windows operating system newer than Microsoft Windows XP, you will get an error message when attempting to run "command" as the utility is no longer included newer windows distributions.

“Command” does not contain all the same logic that “CMD” does, and is limited with the functions, options, and commands that may be executed from within. Due to this, and “CMD” containing newer functions and options, “command” (command.bat) is considered depreciated.

Now, let’s take a look into the revamped “CMD”. Note the differences in the appearance of “command” (command.bat) and “CMD” (cmd.exe).

With the “CMD” (cmd.exe) command line interface window, the first line reads Microsoft Windows XP. (This of course will vary depending if you’re using Windows Server 2003, Windows Vista, Windows 7, etc, however the underlying utility, “CMD”, will function the same.) “CMD” was designed after command, but includes many new functions and features built into it’s logic. Functions that work in “CMD” will not necessarily work in the older depreciated “command”.

Microsoft Windows cmd.exe Utility as seen in a Windows XP Professional (updated up to service pack 3) environment.

Knowing now that there is a difference in “CMD” and “command”, hopefully you may save yourself some headaches caused by running a command from within the incorrect command line interface utility.

In an upcoming post I will dig into the basic commands built into “CMD” and their functions.