Shell Programming: IFS variable
Doc
I'm having a strange little problem that MUST have an answer but I can't
seem to figure it out! I'm using a Bourne shell on SCO Openserver 5.0.5 and
have the following problem:
I'm trying to set the IFS (Internal Field Seperator) variable to a newline
character so I can properly loop thru each line of a command output. Here's
a snip of my code:
IFS='\n'
dex=0
for nxt in `ps`
do
dex=`expr $dex + 1`
e=`echo $nxt|cut -f1 -d' '`
eval jbid_$dex=$e
echo "$dex) $nxt"
done
The problem is that the shell is seperating my lines at each "n" instead of
each newline. It seems evident that my problem is that I'm not actually
setting IFS to a newline character as I'd like. But am instead setting it
to "\" and "n".
Anyone know how to set IFS to a true newline character?
Thanks,
- Don -
Bob Bailin
"Doc" <a...@b.com> wrote in message
news:hwqYa.40450$I_3....@twister.nyroc.rr.com...
IFS=`echo "\n\c"`
Doc
found that NOTHING ends up in IFS when I use that syntax (IFS=`echo
"\n\c"`). And if I try setting it directly (IFS="\n\c"), I'm back to the
same problem. My lines now get seperated on any "n" or any "c" because the
\n and \c are being treated literally by the shell.
Any other suggestions?
- Don -
"Bob Bailin" <72027...@compuserve.com> wrote in message
news:bgtcsr$m48$1...@ngspool-d02.news.aol.com...
Ronald J Marchand
> Thanks for trying, but this did not work. I had tried this earlier and
> found that NOTHING ends up in IFS when I use that syntax (IFS=`echo
> "\n\c"`). And if I try setting it directly (IFS="\n\c"), I'm back to the
> same problem. My lines now get seperated on any "n" or any "c" because
the
> \n and \c are being treated literally by the shell.
>
> Any other suggestions?
>
> - Don -
Top posting is frowned on here.
My default IFS is set to hex 0a in the bourne shell.
Try echo $IFS | hd and see what you get.
Ron
Ronald J Marchand
> Thanks for trying, but this did not work. I had tried this earlier and
> found that NOTHING ends up in IFS when I use that syntax (IFS=`echo
> "\n\c"`). And if I try setting it directly (IFS="\n\c"), I'm back to the
> same problem. My lines now get seperated on any "n" or any "c" because
the
> \n and \c are being treated literally by the shell.
>
> Any other suggestions?
>
> - Don -
Correction ....
# IFS=`echo "\n\c"`
# echo "$IFS" | hd
0000 0a .
0001
ron
Doc
news:bgthfr$ig9$1...@sun-news.laserlink.net...
My sincere apologies for "top-posting".
- Don -
Doc
I figured out the fix to my problem. The solution is to use CTRL-M and
quotes. In my shell script, setting IFS now looks like this:
IFS="
"
The second quote is on the next line because I hit "Control-M" after the
first quote.
Thanks to all for thinking about it for me.
- Don -
scriptOmatic
IFS='
'; # set the IFS to a NEWLINE
--
http://ftp.opensysmon.com is a shell script archive site with an
open source system monitoring and network monitoring software package.
Many platforms are supplied already compiled.
Bob Bailin
Not obvious at first, but simpler than I thought:
IFS='
'
What this means is, type: IFS=<single quote><enter key><single quote><enter
key>
After you type the 1st enter key, you'll get your shell prompt to continue
entering the command.
The 1st enter key is treated as a line feed (ctrl-J), not as a termination
character, because
of the single quote, which starts a string that escapes almost all
characters from
the shell. The second single quote ends this string and the 2nd enter key
ends the command
$ echo "$IFS" | hd
0000 0a 0a
0002
The 1st "0a" (line feed) is from the IFS variable, the 2nd is from the echo
command.
What you really want to see is:
$ echo "$IFS\c" | hd
0000 0a
0001
Bob
Bela Lubkin
Others have showed you:
IFS='
' # actual newline in quotes
My usual idiom for what you're doing is:
ps | while read nxt; do
...
done
But there's a gotcha here. The Bourne shell forks a separate shell for
a set of shell commands that are being piped to. It does a decent job
of hiding this fact, but your:
eval jbid_$dex=$e
statements won't come through. The variables $jbid_xxx will get set in
the sub-shell, but they won't exist by the time you come to try to use
them, back in the parent shell.
The Korn shell does not fork a separate shell in this situation; running
the same script under `ksh` would make it work. It was a design goal of
ksh to eliminate these language oddities where the scope of a variable
is constrained by forces outside your control.
>Bela<
John DuBois
>I figured out the fix to my problem. The solution is to use CTRL-M and
>quotes. In my shell script, setting IFS now looks like this:
>IFS="
>"
>The second quote is on the next line because I hit "Control-M" after the
>first quote.
Control-M produces the same effect as hitting the return key. Whether you hit
the return key or press control-M, the resulting ^M character is mapped to a
newline by the line discipline (or your editor). You'd get the same effect (it
would work) regardless of whether you typed IFS="<control-M>" or
IFS="<return>".
John
--
John DuBois spc...@armory.com KC6QKZ/AE http://www.armory.com/~spcecdt/