As you cite: “The stty utility is compliant with … POSIX … The … operands … speed, raw, … size … are extensions to that specification”

That was really what I was trying to communicate – not that it is a Linux feature, but that it’s a non-POSIX feature. I only had Linux and Solaris machines to hand when I posted; thanks for confirming that it works on the *BSD systems too.

Regarding “diff” – I was using GNU diff; sdiff can be useful too, but this post was inspired by a Linux-centric installation I have been working on where I can be sure of bash and GNU diff.

As a related item – I should probably post an entry on this subject – when writing scripts which assume (say) bash, the first line must say “#!/bin/bash”, not “#!/bin/sh”. It may even be necessary to get more specific, even to the level of “#!/usr/local/perl/perl5.8/bin/perl” if you require a certain feature, so that you can be sure that you have documented your requirements

“The stty utility is compliant with the IEEE Std 1003.1-2004 (“POSIX”) specification.

“The flags [-ef] and the operands speed, crtscts, iuclc, imaxlabel, onlcr, olcuc, oxtabs, onoeot, echoke, altwerase, mdmbuf, flusho, pendin, xcase, tty, crt, kerninfo, columns, cols, rows, dec, extproc, raw, size, the compatibility modes and the control operations are extensions to that specification.”

Your use of “diff”, though, is not very portable

I prefer the explicit mangling and unmangling of IFS, though this is also valid for all shells I am aware of.

Background:

VAR1= [VAR2= ...] command

Above line sets and exports the environment variable(s) VAR1, VAR2, … ONLY for the the environment of “command”. It will not change the setting for the current shell.

Example:

#!/bin/sh
while IFS=, read qty product customer
do
# process the information
echo “$customer wants $qty $product(s)”
done < myfile.txt

Using bash-specific stuff is fine, if we are sure of having bash installed; if not, then we need to be more generic in our approach

a=1
b=2
c=3
d=$(( $a + $b $c ))
echo “$d”

unlike expr, dc, and bc, this requires nothing more than the shell, and requires no exec calls (and no binaries to be read in from disk).

Using ksh on Solaris, I ran this:

$ set|grep IFS|od -c
0000000 I F S = ‘ \t \n
0000010
$

This shows that IFS consists of a space (” “), a tab (“\t”) and a newline (“\n”).

This is the correct setting for IFS.

“od” stands for “octal dump”, and “od -c” displays each character as a byte. The “0000000″ and “0000010″ are the offsets (in Octal, base 8); the relevant stuff is the “I F S = ‘ \t \n” part.

Hope this helps.

Maybe I should write a post about od some time… it’s a strange and arcane command, but it does sometimes turn out to be very useful.

$ set | grep IFS
HZ=’ ‘
IFS=’
‘

Can someone tell is this IFS environment in KSH set correct by default?

Jonny thanks for your comment regarding line break seperator, it was of great help.

Keep up the good work.

cheers
pai

Both work as described. It all comes from more or less the same place, so I would expect no less on any recent operating system.

I like your blog…keep up the good work.

^______________^