Re: more splitting

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.)

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.

> 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.