Re: more splitting

On 2026-04-14 19:02, Bart Schaefer wrote:

Sheesh.  I suppose it's naive, but one might have thought that whether a 
function gets it's input via the front door or the back door wouldn't 
matter very much.  But it would seem that if the pipe requires all this 
special handling, then it's just not worth it.

print -rn ${(q+)var} | hex


I'm not going to remember that in the real world.

Anyway I'm determined to stop guessing and find some way of seeing 
exactly what makes some hunk of data split this way or that way.  If 
it's NULs, then I want to see the NULs.  One can understand that a given 
piece of data might be optionally viewed one way or another, via 
options, without changing it.  But there do seem to be actual 
transformations happening all the time.  Again, one might have thought 
that it would be possible to pass around a piece of data unchanged.

7 /aWorking/Zsh/Source/Wk 2 % print -rn -- $var | od -vAx -tx1 -tc
000000  61  20  62  20  63  0a  64  20  65  20  66  20  67  20  68
          a       b       c  \n   d       e       f       g       h
00000f

7 /aWorking/Zsh/Source/Wk 2 % hex $var

'a b'
$'c\nd e f g h'

-----------------------------

000000  61  20  62
          a       b
000003
000000  63  0a  64  20  65  20  66  20  67  20  68
          c  \n   d       e       f       g       h
00000b

... 'flat' output shows 15 bytes of data, bottom shows 14 bytes. It's 
missing the space between 'b' and 'c' cuz, I suppose, splitting is on 
spaces but there's a space between 'a' and 'b' and there's no split.  
How do we know which is which?  How is that actually indicated?  The 
above can't be the whole story, cuz there's no indication of which 
spaces split and which don't.  We know it when we create the variable, 
because of the quotes.  But how is that information actually stored?  
There's a split between 'b' and 'c' so how do I know it's a space that's 
responsible (cuz it's been removed) or maybe a newline or a nul.