Re: path PATH

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Sat, Jan 28, 2023 at 8:42 AM Ray Andrews <rayandrews@xxxxxxxxxxx> wrote:
>
> Could give 'em names unlikely to be used elsewhere.  I've seen that sort
> of thing.  Or is there a better way?  Given the branching and switches,
> I can't think how to do it in one string of pipes w.o. intermediate
> variables.  And variables to hold the switches.

You're already resorting to a subshell for
>              line+=$( typeset -m -- ${(b)1} )
So why not get rid of "line", go back to printing everything to
stdout, and (if you still need to) put the entire function call in
$(...) ?  Instead of forking for each parameter, fork once for the
whole main body of the function.

As far as I can tell, "case" is the only bit that matters to finding
the parameter names (although you could do hidden/not without piping
to grep).

So your $case is for example ${~${1:#*C*}:-'(#i)'} which you can feed
into the arguments of dp.

Take a look at the way the "untie" function I posted elsewhere takes
care of managing the list of typeset switches needed to preserve the
attributes of the parameter that's left behind after untying.

> Anyway the whole exercise is just a 'cry for help' -- typeset -p (or
> typeset -P) should give us full disclosure.

You're the first person in 30+ years to ask for this, so it's not
surprising that it hasn't been done so far.  I still don't really
grasp why this is helpful to you (especially when what you do with is
it squash it down to a bunch of cryptic one-letter abbreviations).

> And the doc should discuss *all* the attributes in one place.

They are all discussed in the documentation for "typeset", they're
just not all laid out in a table.