Re: declare -p and -H (hideval)

[Daniel Shahaf <d.s@xxxxxxxxxxxxxxxxxx>]

Bart Schaefer wrote on Mon, May 15, 2017 at 13:03:09 -0700:
> On May 15,  1:36pm, Daniel Shahaf wrote:
> }
> } Bart Schaefer wrote on Sun, May 14, 2017 at 10:22:07 -0700:
> } > It'd be quite simple to make -pm behave differently
> } 
> } I went down the rabbit hole, and it seems pretty sane so far:
> 
> This (changing the default behavior of -p) isn't where I'd have gone
> with this.  I'd have e.g. added PRINT_INCLUDEVALUE to the flags in
> the case of -m and -p used together.

The logic I aimed for was: the -p flag shouldn't affect whether the
value is printed, regardless of whether the positional arguments are
parameter names or parameter name glob patterns.  I.e., make -p and -m
orthogonal.

> Even in your patch, I don't see any purpose to PRINT_ALL that isn't
> covered by _INCLUDEVALUE.

So it's correct but redundant/duplicative?  Understood.

> } +    { PM_EXPORTED, "exported", 'x', 0},
> } +    { PM_HIDE, "hiding", 'h', 0},
> } +    { PM_HIDEVAL, "hidden value", 'H', 0}
> 
> I don't think it's quite that easy.  For one thing PM_HIDE can be
> attached to a top-level variable, but has no effect there, so it's
> not clear whether to include it in the typeset output or if instead
> it needs special handling ala PM_EXPORTED.

I assume you're referring to this block of printparamnode()? —
.
	    } else if ((pmptr->binflag != PM_EXPORTED || p->level ||
			(p->node.flags & (PM_LOCAL|PM_ARRAY|PM_HASHED))) &&
		       (p->node.flags & pmptr->binflag))
.
I think that simply makes sure that "-x" won't be printed for exported
variables, since the command name was alredy printed as "export" for
them?

In any case, I'd lean towards preserving the -h bit on top-level
variables, just on general principles of making «eval $(typeset -p)» as
idempotent as possible.

Is anything else wrong with extending pmtypes in this manner?

Thanks for the review.

Cheers,

Daniel