execute bash?

[wobbles via Digitalmars-d-learn]

On Sunday, 10 April 2016 at 00:47:28 UTC, Puming wrote:
> On Saturday, 9 April 2016 at 08:56:17 UTC, wobbles wrote:
>> On Friday, 8 April 2016 at 23:06:06 UTC, Puming wrote:
>>> On Friday, 8 April 2016 at 18:23:32 UTC, wobbles wrote:
>>>> On Friday, 8 April 2016 at 16:07:13 UTC, Adam D. Ruppe wrote:
>>>>> On Friday, 8 April 2016 at 15:20:09 UTC, Puming wrote:
>>>>>> I tried with signal, but didn't catch SIGTTOU, it seems 
>>>>>> that spawnProcess with `bash -i -c` will signal with 
>>>>>> SIGTTIN.
>>>>>
>>>>> Oh, surely because it wants to be interactive and is thus 
>>>>> waiting for user input from the terminal..
>>>>>
>>>>> You might need to rig up a pseudo terminal that the bash 
>>>>> can talk to. That's getting to be a pain though.
>>>>
>>>> You could run it through dexpect to get the effect of a 
>>>> pseudo terminal.
>>>>
>>>> https://github.com/grogancolin/dexpect
>>>
>>> Looked in the code, it is exacly what I need! Thanks.
>>>
>>> Also it has spawnInPty
>>
>> Cool. Any questions on using it let me know. I'm all for a bit 
>> of feedback also!
>
> I tried dexpect, now it works for the bash emulation!

Good - glad it works!

> But there are still some issues:

Bad - but to be expected :)

> 1. Spawn's data is a string, so it stores ALL data, but Expect 
> class does not have a clear() method, so the data piles up and 
> takes memory.

Yeah, this was something I came across too but didn't have the 
time to fix it.
My plan is to have the Expect class take an OutputRange, and all 
output is then sent to that Range. The only data that it keeps 
track of then is the data just before and since the latest 
'expect' call.

> 2. There seems to be a visible lag for each send->read cycle. I 
> haven't look in the details to find where, but it feels not as 
> smooth as ssh does.

I have added a good few Thread.sleep function calls in the send / 
read calls. This is because it seemed to crash out when there was 
nothing there and I needed something quick to get it working at 
the time. There must be a better way of handling this though.
Also, I suspect I've added way too many sleep calls so I should 
do a bit of work on this!

> 3. when hiting 'vim a.file' on the command, things go messy. 
> Have you got these interactive commands work in dexpect?

Yeah, dexpect won't be handling something like vim. As Adam said, 
it sends lots of signals / commands to the terminal to tell it 
how to draw the window. Dexpect just cares about reading the data 
sent to/from the process, not what any of that data means.

> My wish list for the Expect class ( or design a separate class, 
> like BashProxy ):
>
> 1. Fully proxy for a bash shell.
> 2. Result data are separated for each command. So I can easily 
> search for hitorical sent commands or results.

This would be cool. I'll have a think about how to go about it!

> But for now it works fine for my needs.
> I'll try to improve it when I get major parts of my repl lib 
> done.

Also, pull requests are welcome :)