Re: Which string capabilities need script interpreation?

[Florian Weimer]

* Thomas Dickey:

>> aaa+rv has this:
>> 
>>    sgr=\E[%?%p2%t4;%;%?%p4%t5;%;%?%p6%t1;%;%?%p1%p2%|%p3%!%t7;
>>      %;%?%p7%t8;%;m\016,
>
> actually it looks okay to me:
>
>       sgr=\E[
>               %?
>                       %p2
>                       %t4;
>               %;
>               %?
>                       %p4
>                       %t5;
>               %;
>               %?
>                       %p6
>                       %t1;
>               %;
>               %?
>                       %p1%p2%|%p3%!
>                       %t7;
>               %;
>               %?
>                       %p7
>                       %t8;
>               %;
>               m\016,

The result of %p1%p2%| is never consumed, so it can be left on the
stack if that branch is ever executed.

>> I think this does not result in a balanced stack.  These in
>> ndr9500 have this problem, too:
>> 
>>   pfloc=\E|%{48}%p1%+%c2%p2\031,
>>   pfx=\E|%{48}%p1%+%c1%p2\031,
>
> These are almost the same.  It's adding ASCII "0" (48) to the parameter,
> and printing the result as a character.  That "2" or "1" after the "%c"
> seems to be a literal value.

In both cases, the value of %p2 is left on the stack.

>> tek4107 uses %! throughout, but I think it's actually to be sent
>> verbatim.  sgr0 is particularly clear in this regard, I think:
>> 
>>   sgr0=\E%!1\E[m$<2>\E%!0,
>> 
>> sgr0 does not take any parameters, but may need to access variables,
>> as can be seen in wy350:
>> 
>>   sgr0=\EG0\E(\EH\003%{0}%PA%{0}%PC,
>> 
>> So I think %! in sgr0 needs to be quoted.
>
> I see - perhaps another check in tic, to warn about quoting that may be
> needed for output-strings that should use escaping -- along with making
> tputs remove the escapes.  The existing codes (including Solaris) kind
> of assume that strings that don't take parameters aren't processed with
> tparm, making them ready for use in tputs.

Hmm.  Yes, if there used to be an assumption that parameter-less
capabilities wouldn't need % processing, that would explain why it's
so difficult to come by information which capabilities need %
processing.  Originally, you would just have used the parameter count
list for that.

>> > $<...> are padding (time-delays)
>> >
>> > and yes, since strings are fed into tparm as data, those could
>> > be a nuisance.  Since tputs/putp are supposed to accept either
>> > the result from tparm/tiparm _or_ a string from the terminal
>> > database, it would be in-scope to improve the %s part by escaping
>> > the dollar-signs (and backslash-characters, of course).
>> 
>> I'm wondering if it would be okay in an alternative implementation to
>> only honor $<…> that already part of the terminfo entry.  Basically
>> recognize it at the same time as the % directives, and ignore whatever
>> strings come in via %s (or other constructs), or strings that are
>> written directly.
>
> At the moment I'm curious if making tputs handle some escapes would
> be enough.

What do you mean by that?  Escaping the output of %s, so that it
cannot contain $< accidentally?