Re: more splitting

On 2026-04-14 20:26, Bart Schaefer wrote:
> On Tue, Apr 14, 2026 at 7:45 PM Ray Andrews <[email protected]> wrote:
>> 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.
> This is sort of like saying you expect eating a handful of cookies to
> be the same as eating a bowl of unbaked dough.  (Sorry, that's about
> as far as the analogy goes here.)
It does seem so.  Perhaps the piping mechanism is less sophisticated 
than passing a variable.  One could imagine them being equivalent but I 
quite understand that reality could be different.
> Arguments ($@) are a list of words that the shell has already divided
> up.  Pipes (and other sorts of file input) are a stream of bytes.
> Some extra work has to be done to make the two appear the same before
> you can compare them.
Yeah, that gets to the heart of my issue.  It's this 'shell has already' 
... how?  Where is the information stored? When you say 'stream of 
bytes' in my mind that stream must include whatever information is 
needed to determine the split.  Where else could the information 
reside?  See what I mean?  It almost sounds like there's the data and 
there's some meta-file that stores how it's to be split and when you 
pipe, that info is lost.  But a variable argument retains that 
information.  Were does that information live?

% var=("a b" '\n''d e f'' ''g h')

... if the quotes were preserved in the variable itself there'd be no 
mystery -- I'd do my hex dump and see the ticks and that would indicate 
which spaces are delimiters and which are merely spaces. Easy.  And I'd 
see where newlines are delimiters and when they live as characters in 
strings. And the infamous NULs would show up too.

I get the feeling I've *finally* at least elucidated my ignorance.

Will chew on code below tomorrow.
>
>> print -rn ${(q+)var} | hex
>>
>> I'm not going to remember that in the real world.
> If you redo 'hex' to accept the name of the variable instead of the
> expansion of the variable, you can fix all of this:
>
> function hex ()
> {
>      local _hex_var element
>      echo
>      if [[ -p /dev/fd/0 ]]; then
>         read -d '' -r _hex_var
>      else
>         _hex_var=$1
>      fi
>      set -- ${(P)_hex_var}
>      print -rC1 -- ${(q+)${(Q)@}}
>      echo "\n-----------------------------\n"
>      for element ("$@") print -rn -- $element | od -vAx -tx1 -tc
> }
>
> hex var
> print var | hex
>
>> 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.
> More on this later.
>