Command line and GUI operations don't mix

When unzipping files (zipped originally under DOS) all permissions are messed up; notably the 'x' bit for shell scripts. That's nothing new really – always something to be aware of.

We have a set of Oracle installation (Linux) scripts that are stored on a Windows server. When needed, Dave "the NumbThumb" zips them up and sends them to us to play with. We are well used to adjusting access permissions, in fact we have a little script that looks after attributes of files that arrive from the dark side.

Today I've realised that mixing command line and GUI file manager is no good. Martin opened a GUI file manager and tried to run one of the scripts by double-clicking on the icon. Instead of running, an editor was opened. We quickly realised that the 'x' permission was missing. So I dropped into the command line, and did a quick:

# chmod +x *.sh

Run ls –l to confirm the change – OK. Martin tries to run the script again, but no difference: script didn't execute, but the editor opened again. Conclusion: if you have a GUI screen showing file icons, and change file attributes from the command line, don't expect GUI to take any notice.

The whole experience proves the very old recommendation of working with UNIX : when working on any particular task it’s best to stick to either the command line or GUI, don't mix them!

Playing cat and mouse with the cat builtin

Teaching Fundies. Using cat. Straightforward, hey?

One example in the book says, that you cannot redirect file onto itself using cat.
What should happen is:

$ cat file5 > file5
cat: file5: input file is output file

Delegates try this - "Alina, it doesn't work!". What does happen is:

$ cat file5 > file5
$

Several minutes of experimenting, and one of the delegates shouted with satisfaction: "Got it - cat is a built in".

What? As surprised as I was, in the ksh-20050202-1 cat is a builtin, in addition to the standard /bin/cat.

$ type cat
cat is a shell builtin version of /bin/cat

It may be a builtin implementation of /bin/cat, but there is behavioural difference. Perhaps not because of changes to what or how the two cat versions work, but due to the fact that one (the builtin) is operating in the same process as the calling shell, the other (/bin/cat) gets its own process space.

This could have VERY serious implications for shell scripts!

Consider the following:

$ cat x > x
$ echo $?
0

Then try the same, this time using external version:

$ /bin/cat x > x
/bin/cat: x: input file is output file
$ echo $?
1

How many programmers use full pathnames in their scripts? If you are one of them – well done, and you will have no problems with this particular cat!

If not, however (admit it!), any script written in the past, that uses cat's exit status will fail when ported to this version of ksh.

OK, so why would you like to use cat for testing? I don't know – but that's not the point!

Amazing resource page

When looking for an on-line IP subnet calculator during a class, we came across the site that managed to pull together a fantastic number of network and computer relating tools and resources.

The site itself is an American ISP. If they were in the UK, I would probably be talking to them about their services. Anybody who put so much effort and intelligence into creating this site would be worth considering...

A lesson to learn ;-)