why isn't IFS=$'\n' doing what I expect it to do here?

why isn't IFS=$'\n' doing what I expect it to do here?

[TJ Luoma]

I don't understand why IFS=$'\n' doesn't seem to be doing what I'd expect here:

$ cat test-arrays.zsh
IFS=$'\n' APPS=(
		Alfred 2

		Bartender

		ddnsa

		Fantastical
		Flycut

		HazelHelper

		MagiCal
		MenuBarFilter
		Mountain

		Should I Sleep
		SizeUp

		Trickster
)

echo "5 is: $APPS[5]"

for f in $APPS
do

	echo ">$f<"

done


(Result of the command is)

5 is: Fantastical
>Alfred<
>2<
>Bartender<
>ddnsa<
>Fantastical<
>Flycut<
>HazelHelper<
>MagiCal<
>MenuBarFilter<
>Mountain<
>Should<
>I<
>Sleep<
>SizeUp<
>Trickster<

I thought that IFS=$'\n' would make it so I didn't have to escape the
spaces in the lines which had them.

If I take OUT the IFS line and escape the spaces, it works as I'd expect


APPS=(
		Alfred\ 2

		Bartender

		ddnsa

		Fantastical
		Flycut

		HazelHelper

		MagiCal
		MenuBarFilter
		Mountain

		Should\ I\ Sleep
		SizeUp

		Trickster
)

echo "5 is: $APPS[5]"

for f in $APPS
do

	echo ">$f<"

done

(Result of the command is)

5 is: Flycut
>Alfred 2<
>Bartender<
>ddnsa<
>Fantastical<
>Flycut<
>HazelHelper<
>MagiCal<
>MenuBarFilter<
>Mountain<
>Should I Sleep<
>SizeUp<
>Trickster<

Re: why isn't IFS=$'\n' doing what I expect it to do here?

[Phil Pennock]

On 2013-03-23 at 22:01 -0400, TJ Luoma wrote:
> I don't understand why IFS=$'\n' doesn't seem to be doing what I'd expect here:
> 
> $ cat test-arrays.zsh
> IFS=$'\n' APPS=(

This isn't command or parameter expansion, or reading data with the read
builtin.

IFS would apply if you put the data into a variable and then caused
parameter expansion with splitting on IFS, eg by using the = parameter
expansion modifier, or setting sh_word_split.

This is input parsing, for assignment to a variable, not parameter
expansion.  Mind, that doesn't mean that thinking through this isn't
giving me a headache.

----------------------------8< cut here >8------------------------------
% APPS=(${(f)${:-'
Alfred 2

Bartender

ddnsa

Fantastical
Flycut

HazelHelper

MagiCal
MenuBarFilter
Mountain

Should I Sleep
SizeUp

Trickster
'
}} )
----------------------------8< cut here >8------------------------------

Is that closer?

Note though that leading (and trailing) whitespace becomes significant.

Similarly, you can use:
  APPS=(${=${:-'
for the first line, to actually split on $IFS, in which case changing
IFS does affect parsing here.

-Phil

Re: why isn't IFS=$'\n' doing what I expect it to do here?

[TJ Luoma]

[-- Attachment #1: Type: text/plain, Size: 716 bytes --]

On Sat, Mar 23, 2013 at 11:09 PM, Phil Pennock <
zsh-workers+phil.pennock@spodhuis.org> wrote:

>
> Is that closer?
>
> Note though that leading (and trailing) whitespace becomes significant.
>
> Similarly, you can use:
>   APPS=(${=${:-'
> for the first line, to actually split on $IFS, in which case changing
> IFS does affect parsing here.
>
> -Phil
>

If I do that then I can no longer use "$f[5]" to refer to the 5th _line_ …
I end up getting a single character instead of a line.

That said, at least I understand why it's not working as I expected it to.

For my purposes, I think "APPS=(" is fine, I'll just need to remember to
escape the \ or wrap everything in "

Thanks!

TjL

Re: why isn't IFS=$'\n' doing what I expect it to do here?

[Bart Schaefer]

On Mar 23, 10:01pm, TJ Luoma wrote:
}
} I don't understand why IFS=$'\n' doesn't seem to be doing what I'd expect

Um, because you're expecting the wrong thing?

(I'm pretty sure this was answered on the list not that long ago, but
danged if I can find the message.)

IFS does not affect the shell's parsing of its own script language.  If
it did, all sorts of scripts would fail any time IFS were exported into
the environment.

(Below here updated slightly because Phil's answer came in while I was
typing.)

As Phil mentioned, what it DOES affect is:

- Splitting or joining of words in shell expansions/substitutions

- The interpretation of input strings e.g. via the "read" builtin
  or "vared"

So as an alternative to Phil's parameter expansion trick, you can do
this:

IFS=$'\n' read -d '' -A APPS <<-\APPS
	Alfred 2

	Bartender

	ddnsa

	Fantastical
	Flycut

	HazelHelper

	MagiCal
	MenuBarFilter
	Mountain

	Should I Sleep
	SizeUp

	Trickster
APPS

(Note this returns 1 because read encounters end of file before it finds
the empty separator.  Since it won't ever find the empty separator, it
may be that this should be made a special case that returns zero.)

Re: why isn't IFS=$'\n' doing what I expect it to do here?

[Phil Pennock]

On 2013-03-23 at 23:27 -0400, TJ Luoma wrote:
> > Similarly, you can use:
> >   APPS=(${=${:-'
> > for the first line, to actually split on $IFS, in which case changing
> > IFS does affect parsing here.
> >
> > -Phil
> >
> 
> If I do that then I can no longer use "$f[5]" to refer to the 5th _line_ …
> I end up getting a single character instead of a line.

Then something is strange in your environment.

The (f) forces splitting on lines, resulting in an array, and is
assigned inside APPS=( ... ).

Similarly for the = (which uses $IFS to split).

I've just confirmed with "zsh -f" that this works just fine with default
options.  I suspect that you missed the outer ${(f) ... } wrapper.

-Phil