Re: psychiatric help

[Ray Andrews <rayandrews@xxxxxxxxxxx>]

    Bart:  Will digest this and get back to you
      but a few preliminaries:

On 2026-04-04 20:57, Bart Schaefer wrote:

> By "the command tail" you mean the positional parameters? $*, $@, or
> $1, $2, $3, ... ?
>     
    Yes.  Dunno why that useful bit of jargon isn't current in
    Unix/Linux like it was in DOS.  'Tail' is easier to type that
    'positional parameters'.  
> "Hard" (previously quoted) spaces only become "soft" (unquoted) spaces
> when, well, you don't quote them.
>     
    Everything was fine here until I had this filespec:    junk\ *
    otherfiles*
    ... as I mentioned:  % ls junk\ * otherfiles*
    ... shows what one would expect.  But my function required: % l
    'junk\ *' otherfiles*
    ... cuz, as you say, quoted spaces ('hard' spaces, i.e. part of one
    filename) must stay quoted.  Anyway, the backslash is necessary too
    but it keeps disappearing.  
> On top of that, though, in zsh, quoted spaces only become unquoted
> when you explicitly unquote them.  There are a bunch of ways to do
> that, but the most common are
> - setopt sh_word_split
>     
    I understand that's something to avoid, no?  Not really kosher zsh
    craft, yes? I'm determined to stick within zsh native methods.  
> - ${=var} (temporarily sh_word_split)
> - eval
>
> I'm reasonably sure you're not doing sh_word_split, but based on your
> history of questions you have a habit of using eval.
>     
    True, but trying to get away from it on your advice.  
> I think you're also a bit unclear on the concept of arrays and of
> using double-quotes.
>     
    I know, at least in theory, that args are better passed as arrays. 
    And I sortakinda mostly do that, but all this stuff is invisible,
    you just have to understand the deep magic.  
> array operations on them.  That means you should NOT do
>
> out=${@//\ /\\ }
>
> because that is a string (scalar) assignment,
>     
    Got you.  Yes, I understand.  Will try ...
> so all the elements of
> the $@ array get concatenated together into a single string as the
> value of $out.  That puts you in the position of having to split $out
> apart again to use the array elements.  Given your focus on keeping
> the backslashes, I'd be willing to bet you're doing that with eval.
>     
    Yes.  Again, in theory I understand that I can do all sorts of
    breakit fixit breakit fixit things and I'd rather not break it in
    the first place.  Which is why I don't like my grubby little hack
    and want to do this correctly from the getgo. Nasty thing tho is
    that if stage two is a fixit then I'm obliged to breakit in stage
    one *unless* I can avoid the first breakit *and* then throw away the
    fixit at the same time ... if that makes any sense.  
> If you need to copy $@ (et al.) into another variable, use array syntax:
>
> out=( $@ )
>     
    ... will try.  Understood.
> That preserves all your "hard" spaces in each of the elements of the
> array $out.  Of course if you need to do some other manipulation of
> the individual element values, there may be complications, but the
> basic idea is to stop needlessly converting arrays to strings and
> back.
>     
    Exactly.  'Tis devoutly to be wished.  
> Notice how "$@" and "$*" differ.
>
> "$*" is like "$1 $2 $3 ..."
> "$@" is like "$1" "$2" "$3" ...
>     
    Right, I'm 100% '$@' here.  
> Sadly, I don't know what you mean by "designators".
>     
    'Identifier' is perhaps more correct?  A string of characters
    delimited by a space (unless a hard space)  that refers to a logical
    object: filename, variable, command ... 
    Pardon Bart, I have no formal education in any of this, I'm making
    it up as I go along.