Input redirection into a while loop

I'm teaching shell scripting in Stamford this week. Earlier today we had a discussion about data redirection to/from various programming statements like if, while, etc.

The offered approach was:

while read -r
do
command(s)
done 0< file

One of the students asked if you could have the redirection specified before the while, i.e:

0< file while read -r
do
command(s)
done

My immediate thought was - yes, it should work. I didn't offer my opinion at that point, though. Instead I answered the question with another one. I asked them if the following would work (my favourite example illustrating shell scan):

$ 1> file < /etc/passwd cat 2> /dev/null

I was truly convinced that the original question is another exhibition of the same behaviour, which allows to specify the I/O redirection at any (sensible) point of the command line.

Well, whereas the cat command line above will work OK, the original construct does not work! I have tried various combinations, and deduced that any alias, function or external command can have redirection specified before the command itself. However, when you are dealing with reserved words (programming keywords) or built-ins, the mechanism is not recognised, with a "command not found" error message.

Curious... Need to investigate it further, unless Clive comes back with an answer before then ;-)

URL code/decode tool

NLUG discussion on debugging htmp/php code lead to one of the participants quoting what I thought was an excellent tool for url decoding.

There are also very useful conversion tables.

Mac addresses in VMWare

I have recently noticed that when booting RHEL 4 in VMWare 5 (on my HPnc6120 laptop) the eth0 card would not initialise, with an error "MAC address is different than expected - failed".

After some googling, one theme appeared to recur: hardware modules in the kernel problem. However, I was convinced this was not the issue in my case, since I also have FC 5 and SuSE, to compare the kernel config files against. To complicate the matter further, I went down the totally wrong way to start with, assuming that the correct value was one reported by ip neigh show from another machine on the same home network. How silly of me - that other host was looking at the 'front end' configuration, whereas my problem was sitting behind the VM...

Eventually I managed to fix the problem, but without really understanding the reasons. What was the fix?

Well, I noticed that the HWADDR parameter in the /etc/sysconfig/network-scripts/ifcfg-eth0 had a different value than the one reported by the ip address show command.

I changed the HWADDR value to the one reported by the ip command, restarted the network with service network restart, and all was well. But I couldn't understand why (and how) the configuration file got changed - I could swear that I hadn't touched the parameter - ever! So I continued googling - and eventually went directly to the vmware site (another lesson learnt - should have gone there much sooner!) . The answer is well documented amongst their support pages, under "Maintaining and Changing the MAC Address of a Virtual Machine".

In a nutshell: virtual machine also means virtual MAC. The value assigned is unique, but is liable to be changed if you move the location of your VM.

This is exactly what happened to me. Since creating the RHEL4 VM, I have moved the "My Virtual Machines" folder (yes, XP) to a different drive - to fix XP synchronisation issues... But in turn , that messed up my RHEL installation.

Since my fix did the trick, I haven't studied the solutions they quote on their site - apparently you can tweak configuration files of VMWare itself to fix this.

I'm just happy that there was a 'good' reason for my problems. I hate fixing the unknown... It's just like replacing a blown fuse without knowing why it blew in the first place ;-)