General TELL function to launch external process (exec)

[GoogleCodeExporter]

We need a new TELL function which is capable of launching an external (shell) 
process and eventually to return the result in TELL space.
It might be tricky to achieve full interoperability between the platforms and 
especially on Windows.

Original issue reported on code.google.com by krustev....@gmail.com on 5 Sep 2010 at 10:14

[GoogleCodeExporter]

exec("<external_command>");
introduced in r1685, r1687. Looks stable on Linux despite all the gymnastics 
across the threads (wx requires this kind of activity to be launched from the 
main thread only). The external process input&output is redirected to Toped 
console. Some funny effects can be observed on Linux:
- the output formatting is not always as expected (for example "ls")
- the redirection of the input stream of the external process proves to be 
tricky. The best I could achieve so far is a single portion of input data from 
Toped console. Looks like the external process expects a special character or 
some kind of notification signifying that its input stream is not empty. The 
only way I found to make this notification is to close the stream which works 
fine yet limits the eventual interaction with the process.

The function needs further tests (especially on Windows). Some work on the 
Toped console is also required to make the output from the external command 
distinguishable from the output from TELL and Toped itself.

Original comment by krustev....@gmail.com on 17 Dec 2010 at 6:10

• Changed state: Started

[GoogleCodeExporter]

I checked under Windows. It works not very good.
Created file test.bat contains only dir command.
Result of execution in results.txt
Log of toped in log file

You can see that Toped  swallows some results and has problem
with russian letters

Original comment by gaitukevich.s@gmail.com on 18 Dec 2010 at 3:35

Attachments:

• results.txt
• test.bat
• log

[GoogleCodeExporter]

Hi Sergey,
Can you investigate a little further... I can't see where exactly the trouble 
with non-latin characters is coming from. wx should be compiled with unicode 
support (I believe yours is) and on this particular case we're using only 
wxString all the way from the command output stream to the toped log. 
Theoretically it should not have any troubles with any characters...
It seems that missing characters are in the "same department"
(Just for the record - On Linux having unicode support on - I can't see any 
troubles with Cyrillic characters)

Original comment by krustev....@gmail.com on 19 Dec 2010 at 10:08