The IFS mystery

The IFS is involved in the parsing of the command line (word splitting) and in variable assignment during the read built-in execution.

But there is a side effect, which I have only discovered recently, by accident. If you assign positional parameters with set:

$ set a 'b c' d 'e f'

than using the * parameter we can get at the values individually or as one word. To illustrate, try the following:

$ echo $* "$*"

a b c d e f a b c d e f


However, if you 'nullify' the IFS variable:

$ IFS=""

then the behaviour of the shell when referencing the * parameter changes:

$ echo $* "$*"

a b c d e f ab cde f

This only works with the * parameter (not with @) and only if IFS had a null value (if you inset IFS altogether, then the shell will use a space to separate positional parameters.

Finally, I've checked this behaviour in ksh and bash - same (and documented in manual pages, at least in bash).

Quoting command substitution

When we learn the inner works of a shell, we quickly realise the benefit of using double quotes with request for variable substitution.

For example, to assign a value to a variable (and preserve leading spaces), we would use:

$ address=" 23 Acacia Avenue "

A correct quotation is needed to recall the value complete with the spaces:

$ echo "<$address>"

The less known application of the quotes is when they are around the command substitution syntax. By default, POSIX shells remove trailing new-lines during command substitution. Double quotes change this behaviour!

Compare the output of the following commands:

$ echo $(ls)
log.1 log.2 log.3

and

$ echo "$(ls)"
log.1
log.2
log.3

Graphics problems...

For all its maturity, problems with graphics with installs out of the box are still there... This time, trying to use RHEL4 on an HP machine with Intel 82845G/GL[Brookdale-G]/GE Chipset.


Seems fine, until you try to restart the X Window System with CTL-ALT-Backspace. The screen just goes blank, no message, no GUI - nothing. Log into a character interface, run level 5 is shown, and the startx command works well.


Just wonder, actually... Could it be a setting somewhere stopping the CTL-ALT-Backspace restart deliberately? Will need to do a bit of 'googling'.

Adjusting the kernel for Oracle

In the golden old days, when installing Oracle on UNIX, a laborious kernel recompilation process was often needed, to adjust required memory parameters.

On Linux, the process is much simpler, as most of the significant parameters may be changed 'on the fly', effortlessly, and without as much as a reboot, let alone kernel compilation.

All current kernel parameters may be found in /proc/sys/kernel location. Explore it, to see that each parameter has its own file, with either a Boolean Yes/No (or 1/0) or a string value.

The set of parameters required for Oracle10g (only part of the list is quoted here) says:

shmmax  = 2147483648
shmmni  = 4096
shmall  = 2097152
shmmin  = 1
shmseg  = 10             

There are different ways of implementing it: first of all, you can get the values directly into the memory constructs, for example:

# echo 2147483648 > /proc/sys/kernel/shmmax

This will adjust the value correctly, with the slight drawback - the value will return to whatever the default was after the next reboot.

Alternatively, for a more permanent modification, you can place the required definitions in the kernel configuration file: /etc/sysctl.conf.

kernel.shmmax=2147483648
kernel.smni=4096
kernel.shmall=2097152
kernel.shmin=1
kernel.shmseg=10

and inform the kernel of the changes with:

# sysctl -p

command, which will read the values from the sysctl.conf file and place them in the
appropriate files under /proc/sys/kernel.
Any subsequent reboots will also make use of these values.