Re: counting trouble

[Ray Andrews <rayandrews@eastlink.ca>]

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.