[BRLTTY] Feature request: configurable prompt pattern

[Nicolas Pitre]

On Wed, 14 Mar 2018, Dave Mielke wrote:

> It's just that network security wasn't understood very well back 
> then so the higher management was putting too much trust in the people who had 
> that job at the time.

My boss at a former job had to put a PC under his desk. That PC would 
establish an outbound ssh connection to a few remote employees with port 
forwarding so we could effectively connect back into the company's 
network. This backdoor was the only way to do it as the IT people would 
simply refuse to provide any incoming access, not even with VPN boxes. 
And the ssh connection would use the https port of course, as anything 
else was blocked. This arrangement lasted for a couple years and went 
undetected all that time.

> I set up the login profile for their account with a prompt which stated that I 
> believe Bible reading to be good for people so would they please first read one 
> chapter from the Bible and then enter into the prompt which chapter it was. The 
> prompt stated that this was all on the honour system, and that I was assuming 
> them to be honourable people who'd answer truthfully.

Did they ever log in?

> >Oh absolutely.  We do have too many functions that can be bound already.
> 
> Well ... we could start using long presses. The problem with this, however, is 
> that some braille devices don't support them. What I mean is that pressing a 
> key on some of them immediately sends the release so we can't tell how long it 
> was pressed for. So long presses are useful for devices that support them, but 
> we can't use them as a general solution.

Maybe that could be useful if someone wants to move between two 
different types of prompts. But I think that for now, simply providing 
the ability to change the current prompt matching should actually cover 
most advanced use cases.

> >Well, obviously that default regexp is an internal detail. It is just 
> >the default value when the config file option is not provided. This way 
> >the implementation is kept simple with only one method.
> 
> I prefer if-then-else, i.e. if it's set then use it else use the current code. 
> There are two reasons for this. One is that we need fallback code, anyway, in 
> the case that autoconf says that we can't use regular expressions. The other is 
> that it prevents surprises from creeping into the default case.

Fair enough.

> >Indeed. But like the initial proposer suggested, the content from all 
> >backref substitutions would have to be filtered so regexp special 
> >characters are turned into literals..
> 
> I missed that one. In any case, I don't think that the comlexity of creating a 
> dynamic regular expression would really give us all that much extra.

Maybe not. That could be extended eventually if need be. For example:

prompt_match = |<regexp>|  # that's a direct match

prompt_match = |<regexp1>|<regexp2>|  # that's the ultimate match

No need to implement the later initially.


Nicolas