What to do when the system libraries go away…

You’ve been hacking away at this system (let’s be positive and upbeat and say it’s a test system and not production). Through a slip of the fingers, you move the system libraries out of the way – all of them. Now nothing can find the libraries. Now what? Is everything lost?

Don’t despair! You can do a lot without libraries. Already loaded software has the libraries in memory, so that is okay. This includes the shell, so the shell should be okay.

There may be some statically compiled binaries on the system that don’t require libraries; these can be run. If a scripting language like perl or ruby is statically compiled, then all is well – these languages can do anything, and can replace binaries (temporarily) such as mv, cp, and others. However, since vi is probably not statically linked, you may have to do it at the command line (and not in an editor).

Here are some things one can do:

echo *

Through the use of the shell’s filename expansion, this works out to a reasonable imitation of ls (ls -m, in particular). If you have to empty a file (make the contents nothing), use this command:

> file

Every standard utility today is dynamically linked; this means that in situations like these you are stuck with only what the shell itself provides. Remember that things like cat, ls, mv, cp, vi, rm, ln, and so on are all system executables – and quite possibly dynamically linked.

The best thing for a situation like this is to have prepared in advance – have a copy of busybox handy, and possibly a statically compiled perl or ruby (or both). Don’t forget editors – either have a copy of e3 or of a statically compiled editor. Busybox provides all the standard utilities in one statically created binary, and e3 is an editor that is tiny (and i386-specific) which emulates vi, pico, wordstar, and emacs (based on its name).  Neither busybox nor e3 require additional libraries.

A good tool (and a good tool in case of security breach) is a small CDROM of tools, all statically linked for your environment. Such a disk requires no libraries at all – and could have all of these necessary tools and more.

Of course, the best thing is to avoid doing this kind of thing in the first place…

Using Perl to make big files

A while ago, I talked about making big files. This was, by nature, UNIX-specific – that’s what I deal with all day, and the focus of this blog.

However, not all systems are UNIX (or Linux) – and not all the systems I deal with all day long are UNIX or Linux. However, perl is everywhere – and can be used quite easily to generate large files whatever you might be on.

For example, to make a 5M file, try this:

perl -e "open(FD, 'myfile'); print FD 'x' x (1024 * 1024 * 5);"

If you are inside of vim (a vi-clone which also runs everywhere), try this:

:!perl -e "print '-' x (1024 * 1024 * 5);"

This gives you a single line (5 megabytes in size). To make multiple lines:

:!perl -e 'for ($i = 1; $i < 500; $i++) { print "x" x 39, "\n"; };'

This makes 500 lines of 40 characters each (including single-character line terminator). If the system line terminator is two characters, then use 38 instead of 39. In total, this gives 19000 characters (about 18 kilobytes).

Perl is quite useful for creating portable scripts – but is by no means the only one. The ideas given here carry over to other languages that may be available. For instance, tcl and python and ruby are also available in other environments, and can do the same things as perl does here.

Of course, perl’s repetition operator ‘x’ makes it particularly easy here.

Update: corrected perl one-liner.

Writing Portable Administration Scripts

Writing portable scripts for UNIX and Linux is fairly easy – Korn shell is everywhere, and ksh scripts work the same and have the same basic tools available (sed, awk, pipes, etc.).

What about writing portable scripts to work on UNIX, Linux, and OpenVMS? UNIX and Linux are similar enough that things will work across the different platforms – the same holds for the BSD platforms and for Windows with the Cygwin utilities.  But radically different platforms such as OpenVMS require a different approach.

The first thing I did in looking at OpenVMS was to search out the languages and utilities that were available.  HP offers a number of open source tools, and has Freeware CDROMs available as well. SAIC has a large OpenVMS archive, including the contents of the HP Freeware CDROMs.

Under OpenVMS, I found these languages available:

• Java (built-in)
• GNU awk
• Perl
• Perl/tk
• tcl/tk
• Python

I doubt that Java would be used for scripting purposes, but it is becoming ubiquitous and if it is well-known by the scripter, it is possible that it could be used.

However, the other (add-on) alternatives seem to be much more likely.  Perl, Python, GNU awk, and tcl have extensive capabilities, and with tk visual displays are possible.  My main choice would probably be Perl.

The next step is to make sure that any coding that is done is truly portable.  Perl, with its extensive documentation, includes documentation specifically for portability and for OpenVMS as well.

The Perl portability documentation goes into complete detail about the various points that may trip a programmer up; in short, several of the main points cover:

• Data representation (high-endian order? low-endian order? line terminator?)
• File path representation
• Character sets and encoding (including order)
• Time and date representation

The best thing to do is to following the guidelines in the Perl portability document (even if using other languages) and to then test the portable code on all systems affected. Only in extreme circumstances should code be written specifically to the target system and selected based on target OS type.  Better to make it portable at its core.