Windows Vista and Windows Server 2008 now support symbolic links mklink command. See Junfeng Zhang's write up on the mklink command.

For those using Windows 2000 or XP, you'll still need to use junction points to achieve a similar effect. Microsoft has a KB article on creating junction points, but there are some drawbacks to manually trying to manually manage junction points.

Fortunately, there are tools available that ease the pain of using junction points and prevent you from having to know all of the command line options. One such tool is NTFS Link, which provides shell integration for junction points. You can simply right-click in a folder and select New > NTFS Junction Point. Then select the target folder to link to and a "new" folder, named "Link to target folder" will be created in the directory you are in.

So, if you are a Windows user, you now have a couple of different options for creating and using symbolic links!

In Windows:

findstr /s /n /i /p foo *

The above example of findstr will print out the relative file name/path and line number (/n) in a recursive (/s), case insensitive (/i) search for the string foo (foo) in all files (*), ignoring files with non-printable characters (/p).

For a literal string, you can use the /c option:

findstr /s /n /i /p /c:"foo bar" *

There are a number of other options, but those are the ones I use most often. To restrict your search to certain files, just change the * to the pattern you are looking for, like: *.txt or *.css, etc.

For Unix:

grep -rni foo *

The above example of grep will print out the relative file name/path, matching content and line number (-n) in a recursive (-r), case insensitive (-i) search for the string foo (foo) in all files (*).

To search for a literal string, just put the search pattern in quotes.

If you just want to see the relative file name/path and don't care about the line number/content, you can use:

grep -rli foo *

And since these are commands I use all the time, I usually set up "shortcuts", so that I don't have to type out long commands with lots of options.

In Windows, you can create a batch file, called grep.bat for example, with the following:

findstr /s /n /p /i /c:"%1" %2

Then from the command line, just type grep foo *. For this to work, grep.batch needs to be in a folder that is in your PATH environment variable.

In Unix, there are a number of ways to do this, but I tend to just create an alias. For example, from the command line:

alias search='grep -rni'

Then from the command line, just type search foo *. Of course, you can just about any word/letter in place of search, just as long as it's not a reserved/system keyword. Lastly, you can add the alias command to a startup file and it will be available to you every time you log in.

After extracting the 2 files, I opened Ubuntu-7.10-server-i386.vmx in VMWare Player. A dialog appeared asking me if I had moved or copied the image opened, so I selected "I copied it".

After which, I received an "error" saying something like "This CPU is VT-Capable but VT is not enabled ...". It appears that even though the image I downloaded was for an i386 machine, it was defined as a 64-bit machine in the vmx file. After the OS loaded, I logged in (ubuntu/ubuntu) and did a shutdown:

sudo shutdown -h now

I edited Ubuntu-7.10-server-i386.vmx and changed guestOS = "ubuntu-64" to guestOS = "ubuntu". I reopened the file in VMWare Player and then all was fine...

After logging in again, I discovered that I had no network connectivity. I did an ifconfig and noticed that eth0 was missing. So, I tried a sudo ifup eth0 and got the following error:

eth0: ERROR while getting interface flags: No such device

...

SIOCSIFADDR: No such device
eth0: ERROR while getting interface flags: No such device
eth0: ERROR while getting interface flags: No such device
Bind socket to interface: No such device
Failed to bring up eth0

I did a bunch of Google searches and tried a bunch of different "fixes", but ended up finding the real problem. [Background]: When VMWare Player starts up, it generates a MAC address as well as an UUID for the system (in the vmx file).

Well, it turns out that in /etc/udev/rules.d/70-persistent-net.rules file, the MAC address that VMWare generated (ethernet0.generatedAddress) was being assigned to eth1 and therefore, the eth0 MAC address was incorrect. So I edited the file and removed the first entry:

# PCI device 0x8086:0x100f (e1000)
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}="[bad mac]", NAME="eth0"

Then I edited the line with the correct MAC address and changed eth1 to eth0. I read about some commands to run that would make eth0 start working, but I ended up just restarting the OS. After it came back up...eth0 was alive!!!

After searching in a few places (Windows XP), I came across the file that holds this information. It's called preferences.ini and is located in:
[drive]:\Documents and Settings\[user]\Application Data\VMWare

UPDATE: In Windows Vista, the file is located in:
[drive]:\Users\[user]\AppData\Roaming\VMWare

At the bottom of the file, you should see entries like (where X is a sequential number):

pref.mruVMX.filename = "..."
pref.mruVMX.displayname = "..."

Just delete/reorder the entries as desired, save, then start VMWare Player to see the changes. VMWare Player will need to be closed before you make the changes, or they will not be saved.