Re: psychiatric help

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.