MacOS Keyboard bindings

[grbba]

As i understood there is a history of commands so arrow up/down should recall commands in the stack. But on my Mac the up arrow e.g. produces

DccEX> color
Colors ON
DccEX> ^[[A

and nothing happens. Same for autocompletion using the tab key. The following is happening when in succession i type a tab and a back tab:

 - color
        Enable colors in the cli
 - nocolor
        Disable colors in the cli
 - build
        (menu)
 - cs
        (menu)
DccEX> co       ^[[Z

I would have expected autocompletion to give me color ?
//grbba

[daniele77]

Have you tried the complete or pluginmanager examples on MacOS?
Did they work as expected?

[daniele77]

Yes, the error you get a runtime was due to the TCP port already in use. You can change it (e.g., 5001) and the error should disappear.

[daniele77]

In your application, the special keys don't work just because you're using CliFileSession. You should use CliLocalTerminalSession instead (as in the examples pluginmanager and complete).
CliFileSession is meant to be used when the input is feed from a file. CliLocalTerminalSession is the right class to instantiate when you need to exploit all the features of OS shells.
Try with CliLocalTerminalSession and let me know.

Aside note: I see you're using asio asyncrhonous serial port. My advice is not to spawn another thread for the serial port, but to use the same of the boost scheduler you already have for the cli:

boost::asio::io_context ioc;

// use ioc for the serial port
boost::asio::serial_port serial(ioc);
...

// use the ioc for the cli scheduler
BoostAsioScheduler scheduler(ioc);
...
CliLocalTerminalSession localSession(cli, scheduler, std::cout, 200);
...
ioc.run(); // use the current thread for both the serial port and for the cli

In this way, you're using the same thread for cli and serial port, so that you don't need synchronization between those parts.
(see boostasio_nonowner_context.cpp example).

In general, if you use boost::asio asynchronously in your application, you can have "concurrency" using just one thread by having one instance of asio::io_context that manages async events.

Another note: when your class has exclusive ownership of a pointer, use std::unique_ptr instead of raw pointer (e.g., in your pimpl code).

[grbba]

I managed to get it working once i really followed the complete example to the end ... I had also some issues using a thread started by a command from within the lamda of that command because of the use of boost:asio inside the function called when reading from a serial port. My assumption is that some resources never got freed in the serial port and despite being joinable the join blocked on exit somehow and when typing at that point an additional CR/LR I got the error from the library.

That has disappeared when i actually detached the thread ( which is possible as this thread only read incoming messages from the serial port and does nothing else )

[daniele77]

Ok, but please consider don't use a thread but the same boost::asio::io_context for both cli and serial port.

[grbba]

In your application, the special keys don't work just because you're using CliFileSession. You should use CliLocalTerminalSession instead (as in the examples pluginmanager and complete).
CliFileSession is meant to be used when the input is feed from a file. CliLocalTerminalSession is the right class to instantiate when you need to exploit all the features of OS shells.
Try with CliLocalTerminalSession and let me know.

Aside note: I see you're using asio asyncrhonous serial port. My advice is not to spawn another thread for the serial port, but to use the same of the boost scheduler you already have for the cli:

boost::asio::io_context ioc;

// use ioc for the serial port
boost::asio::serial_port serial(ioc);
...

// use the ioc for the cli scheduler
BoostAsioScheduler scheduler(ioc);
...
CliLocalTerminalSession localSession(cli, scheduler, std::cout, 200);
...
ioc.run(); // use the current thread for both the serial port and for the cli

In this way, you're using the same thread for cli and serial port, so that you don't need synchronization between those parts.
(see boostasio_nonowner_context.cpp example).

In general, if you use boost::asio asynchronously in your application, you can have "concurrency" using just one thread by having one instance of asio::io_context that manages async events.

Another note: when your class has exclusive ownership of a pointer, use std::unique_ptr instead of raw pointer (e.g., in your pimpl code).

Thanks a lot for this remark i will definitely try this out as it will make things simpler and more clear. I didn't see this reply before actually sending my comment of 2h ago. Somehow github hid it away from me and I discovered it in my mail :)

Also the unique_ptr issue you raised i will implement.

Again thanks for all your help 👍