Zsh Mailing List Archive
Messages sorted by: Reverse Date, Date, Thread, Author

Re: counting trouble



On 04/04/18 09:48 PM, Bart Schaefer wrote:
But it's NOT lines, any more than the elements of a C array are lines
Ok, I suppose it's worth keeping clear.  In practical terms tho 3/4 of my grief with zsh is line/splitting issues.  I can see that this problem is fundamental to the way the shells work so no salvation is possible, but some way of really getting a grip on things would sure be welcome.

In the shell grammar sense, it's an array of "shell words".
New concept!  Mind, I know what you mean, an array is element based, not 'terminator' based (except for the null of course).  Thing is, that if we could just 'see' the structure things would become more clear.  Interesting that in C none of this is any sort of issue at all, it's always entirely transparent.
}    print -l "${tmp[@]}\n"
}
} ... does exactly what I'm expecting

But print is receiving individual "shell words" as its argument list,
one array element per word.  The -l option causes print to *add* the
line breaks.  If you replace -l with -N you don't get line breaks,
you get nul bytes.
Right, it is worth getting that straight.  I've tended to think of \n's as being actually 'in' the data structure.  And that also makes it clear why I should stop trying to make echo act on newlines -- they ain't there!  But besides output formatting, we also have actual data manipulations and the whole thing is invisible.

There's no perfect way to do that because there's intentionally no
character that you could use to show where the words begin and end
that can't also theoretically appear IN one of the words.
Jesus! How was this sort of thing permitted back in the day? Astonishing that you guys made it all work.
} If I could see the hidden structure of both input and output there'd
} be a lot less guessing.

I'm not sure what you consider to be an "input" and what an "output".

I mean the way we can read in one data structure and save it to another with a different construction.  In view of the above, I'm beginning to suspect that half the time my way of getting things to format has been via trying to change the data structure itself rather than simply controlling output formatting.  This might be easier than I've made it -- we don't 'act' on the newlines, we 'print -l' to get each element on a new line.  That's quite huge. Of course there can be 'real' newlines here and there and that way lies madness.

BTW you were right, in the 'count' issue it does seem I somehow stringified the element -- more invisible spells and curses.

print -l ... yes, now I get it.




Messages sorted by: Reverse Date, Date, Thread, Author