read looses leading spaces

[John Flanagan]

The following script breaks a file up into a number of sections and then e-mails the user. The read statement removes the leading spaces. Is it possible to avoid this?

Regrads,

John.

while read -r f1
do
newtest=`echo $f1 |cut -c1`JF
if [ $newtest = "^LJF" ]
then
mv jf1.txt jf2.txt
cat jf2.txt | ux2dos | uuencode jf.txt | mail fngj@ptipc-144
rm jf2.txt
f1=`echo $f1 |cut -c2-70`
fi
echo "$f1" >> jf1.txt
done < APB003RR.txt_FE_0126_150409
cat jf1.txt | ux2dos | uuencode jf.txt | mail fngj@paipc-144
rm jf1.txt

[Rodney Hills · Accepted solution]

Set IFS to null at the beginning.

IFS=""

This will prevent read from trying to parse "words" out of the input line.

HTH

-- Rod Hills

[Fred Ruffet]

read uses the IFS variable (internal field separator) to separate fields. Its default is space. If you want to take the whole line, including leading space, you musn't cut on spaces. Set it to \n. Example :
$>read a && echo $a
[some spaces]az
az
$>export IFS=\
>
$>read a && echo $a
[some spaces]az
[some spaces]az

example looks bad cause ITRC forum removes leading spaces :/

Regards,

Fred

[John Flanagan]

Life is so easy when you know how.

Thank you.

John.

[A. Clay Stephenson]

Well, one approach is the line command plus the trick of reading from a file descriptor so that sucessive lines from a file can be read.

Try this loop:

INFILE=myfile

exec 4<${INFILE}
f1=$(line <&4)
STAT=${?}
while [[ ${STAT} -eq 0 ]]
do
echo "\"${f1}\""
f1=$(line <&4)
STAT=${?}
done

I think you will find that your spaces are now preserved.
Man line for details.

[John Flanagan]

Hi, I can see that this works but I am not familiar with the exec and associated items.


It also seems to strip some of the control characters in the file e.g. ^L for new page.

Is 4 a buffer number? can exec be used to read and process several files?

Regards,

John.

[A. Clay Stephenson]

4 is a file descriptor. 0 = stdin; 1 = stdout; 2 = stderr. These 3 are always defined and others are added as needed. Whenever a file is closed, the descriptor is available for reuse. Exec is the mechanism that associates a pathname with a file so that
exec 4exec 5>yyy/zzz assiates file descriptor 5 with yyy/zzz for output. You can have several of these going at once. Using line avoids the problem of having to change IFS's between each read if you are processing multiple files.

[John Flanagan]

Is it possible to avoid loosing my ^L character using this method? This inticates the start of a new advice slip.

Thanks,

John.

[A. Clay Stephenson]

Yes, the line command returns a non-zero result when EOF is reached but all the characters are read. We simply need to add a test to see if line read any characters after exiting the loop and if so output them.

INFILE=myfile

exec 4<${INFILE}
f1=$(line <&4)
STAT=${?}
while [[ ${STAT} -eq 0 ]]
do
echo "\"${f1}\""
f1=$(line <&4)
STAT=${?}
done
if [[ -n "${f1}" ]]
then
echo "\"${f1}\"\c"
fi

Note that \c is added to the echo so that no NL is added to this last output.

You are probably more familiar with file descriptors then you know. For example, error messages should be directed to stderr rather than stdout so to do that:

echo "Bad Error" >&2

In this case there is no need for an exec because stderr is already associated with file descriptor 2.