Does double quoting a variable in echo imply a default IFS?

[Peter Heinemann]

I have a variable which is actually three space-delimited "fields":

# print $arecs | vis -n
one\sthree\sfive\n

Consider these outputs.

# echo $arecs
one three five


# echo ${arecs}
one three five

but why....

# echo "$arecs"
one
three
five

Does double quoting possess an un- or unclearly-documented implicit IFS? Note that IFS was (intentionally) not set when the output above was obtained.

Thanks!

[Patrick Wallek]

What version of HP-UX are you using? What shell?

I just did a test and I did NOT see the same behavior.

# export TEST="one 2 three 4 five"


# echo $TEST
one 2 three 4 five

# echo ${TEST}
one 2 three 4 five

# echo "${TEST}"
one 2 three 4 five

# echo "$TEST"
one 2 three 4 five

[Peter Heinemann]

Patrick:

posix under 11.11.

more info which I inadvertently left out..

I created the variable from output of a grep.

Heres the source file:
# cat /tmp/tmp.tmp
one A
two B
three A
four B
five A

Heres the assignment:
arecs=$(grep "A" /tmp/tmp.tmp | cut -f 1)

Not sure if this clarifies or further confuses...

[Rodney Hills]

If their are newline characters between the text, then

echo $arecs
will be parsed by the shell and the new lines will be seen as parameter seperaters, which will be stripped and the arguments will be displayed with the standard OFS (space).

echo "$arecs"
will be parsed by the shell and the contents of arecs will not be parsed and output as is. So embedded new line characters will be displayed along with the text.

HTH

-- Rod Hills

[Peter Heinemann]

Rodney,

$arecs had:
one-space-two-space-three-newline

# print $arecs | vis -n
one\sthree\sfive\n

To extend your explanation a bit, with the variable in double quotes (echo "$arecs"),
if the shell finds *any* newline, all field separators then become newline? e.g., the presence of one newline at the end supercedes the spaces?

[Rodney Hills]

Your "print $arecs | vis -n" is having the same issue as the echo. The shell parser is intefering with the newline characters. Try-

print "$arecs" | vis -n

and I think you'll see the \n in between each text.

-- Rod Hills

[Bill Hassell · Accepted solution]

Unless told differently, spaces are variable delimiters in shell programming. Abything that produces a string with imbedded spaces will have to be quoted if the sring is to be treated as a single entity. This means during the assignment (ie, X="$(grep something)" is a single string). Then when referencing the variable, be sure to flag it as a single string with quotes too (ie, echo "$X"). The quotes don't change IFS, they flag a string as a single entity.

[Bob_Vance]

The var assignment using $(grep ...) caused the variable to contain the newlines at the end of each 'grep'ed line (which is normal and fine, of course).

As Bill said, when you use
... # cmd "$var"
you are telling the shell parser that this is one argument to 'cmd' -- shell does no processing on $var's contents and just passes it as is, newlines and all. Thus, 'echo' sees *one* argument, including the newlines which he dutifully echoes back out.

When you use
... # cmd $var
the shell *is* parsing $var's contents and all whitespace, including newline, is treated as an argument delimiter and is dropped from the arguments passed to 'cmd'. In this case, 'echo' simply sees *3* arguments, with no newlines.

It's similar to:

... # for x in 1 2 3 ; do echo ... $x; done
... 1
... 2
... 3

versus:

... # for x in "1 2 3" ; do echo ... $x; done
... 1 2 3

hth
bv

[Peter Heinemann]

Thanks for the responses, clears it up.
I figured the shell was doing what it was designed to, but could get a clear description of the design...