[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Which string capabilities need script interpreation?
From: |
Florian Weimer |
Subject: |
Re: Which string capabilities need script interpreation? |
Date: |
Mon, 24 Aug 2020 12:53:22 +0200 |
* Thomas Dickey:
> On Sun, Aug 23, 2020 at 09:33:59PM +0200, Florian Weimer wrote:
>> * Thomas Dickey:
>>
>> > On Sun, Aug 23, 2020 at 04:40:18PM +0200, Florian Weimer wrote:
>> >> I'm trying to figure which string capabilities in terminfo files need
>> >> to run through the script interpreter during output. Is this
>> >> information available somewhere? Type information for the script
>> >> parameters would also be nice.
>> >
>> > When you say "script", I'm thinking of the command-line program
>> > by that name. It's not an interpreter -- it simply records the
>> > characters sent to the terminal.
>>
>> I mean the string capabilities with printf-style % directives in them,
>> sorry. In my world, these things look like small scripting languages.
>
> there's simple expressions (arithmetic, logic, formatting),
> but no loops. Long ago, I heard the saying that any interesting
> program has one I/O statement, one loop and one bug. So terminfo
> is missing the second requirement...
>
> man 5 terminfo has this section summarizing the operations:
>
> Parameterized Strings
Yes, that was quite helpful when writing my parser and interpreter.
>> > In terminfo, you have literal strings with some features
>> > added (parameter-substitution, simple expressions and padding).
>> > The tparm function takes those strings along with the actual parameters,
>> > and generates a string that (still containing padding)
>> > can be sent to the terminal using tputs.
>>
>> And I'm wondering if it is possible, based on the capability as such,
>> to tell whether it takes parameters, and what their types are. It
>> helps with adding consistency checks.
>
> tic's checking tries to determine if the capability uses parameters,
> and if they're the proper types. That works well for the predefined
> capabilities (though as usual, there may be some expression that the
> analyzer doesn't get right).
I see, I now see expected_params and line_capability in the tic
sources.
Still it doesn't tell us the types (string vs integer), and whether
there are no parameters.
To illustrate the challenges I see, here are a few examples.
rtpc has this:
tsl=\Ej\EY@%+ \Eo,
But tic lists tsl as just taking one parameter, so %+ cannot work in
this context even with implicit parameter pushing.
aaa+rv has this:
sgr=\E[%?%p2%t4;%;%?%p4%t5;%;%?%p6%t1;%;%?%p1%p2%|%p3%!%t7;
%;%?%p7%t8;%;m\016,
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,
And ti916:
cup=\E[%p1%i%p1%d;%p2%dH,
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 do not really know what is wrong with this icl6404 entry:
csr=\E!%+%p1%{32}%+%p2%{32},
> For user-defined capabilities (other than the ones that ncurses defines
> in its database as extensions -- I added a table of those "recently"),
> that won't work :-)
New user-defined capabilities could perhaps encode the expected
parameter types in their names (similar to C++ name mangling).
> well... hardware terminals wouldn't do that instaneously,
> but there's no data being buffered or blocked -- so it wouldn't
> have been a big problem.
There are instances of sgr0 that also have a delay in them, and it's
not flagged with P, either.
> $<...> 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.
>> This would be a problem for a “set title” capability, if such a thing
>> existed. (It looks like for hpterm, “pfkey” is used in this sense.)
>
> The "hpterm" description has this:
>
> pfkey=\E&f%p1%dk%p2%l%dL%p2%s,
>
> which is (tersely) documented like this:
>
> pkey_key pfkey pk program function key
> #1 to type string #2
> pfkey=\E&f%p1%dk%p2%l%dL%p2%s,
> ^#1 ^#2 ^#2
>
> That \E is ASCII escape, which I've changed in a sample output to "\e"
>
> \e&f5k5Lhello
>
> otherwise generated using
>
> tput -T hpterm pfkey 5 hello
For context, I was going with this:
<https://tldp.org/HOWTO/Xterm-Title-6.html#ss6.5>
Which suggests to use this very sequence to change the terminal title.
> tput uses tparm and tputs, which uses the first parameter in the "5"
> that appears first (using %p1 and %d), and the second parameter twice
> (%p2 and %ld and %d, for a length, and %p2 and %s for a string).
But %p2%l will produce incorrect results if %p2 contains the string
$<…> and padding is processed because the $<…> is not written to the
terminal, so the character count produced by %l is too high.