sorry, I have installed it but not tried it. I'll give it a go this week

On Sunday, February 19, 2023 at 2:27:15 AM UTC tbp1...@gmail.com wrote:

> If nobody complains about it in another week, I'll package it up as a new 
> Leo command.
>
> On Monday, February 6, 2023 at 4:15:40 AM UTC-5 jkn wrote:
>
>> I'll give it a try (kubuntu linux, mainly) and let you know what I find...
>>
>> On Monday, February 6, 2023 at 6:18:42 AM UTC tbp1...@gmail.com wrote:
>>
>>> I've been working on a command to run an external file (@file, @clean 
>>> ...).  I think it is ready, and I'd appreciate it if other folks could test 
>>> it for me.  The idea is that you select a node in the external file tree 
>>> and launch the command.  It works on Windows and Linux but not Mac (I need 
>>> more information about the Mac, and I don't have one for testing).
>>>
>>> As long as the processing program such as Ruby, Python, Julia, is on the 
>>> path (and the file is a known file type) - or you specify it in a @data 
>>> setting node - a new terminal will open, run your GUI or console program, 
>>> and wait for you to close it.
>>>
>>> The new command is the @button node in the attached Leo outline.  I 
>>> suggest copying in into the @buttons tree in your myLeoSettings.leo outline 
>>> and restarting Leo.
>>>
>>> The languages it can handle without adding an @data node - it's 
>>> documented in the command's docstring - are python, shell, batch (for 
>>> Windows), ruby, lua, and julia.
>>>
>>> Here are some technical details -
>>>
>>> This command was hard to get working right on Linux (and I can't swear 
>>> that it will work on Linux if the external file name has spaces), and the 
>>> reason was my requirement to open a new terminal and keep it open after the 
>>> external program finishes.  I want that so that any output can be seen and 
>>> studied.  
>>>
>>> It's easy to launch a program and have it write to Leo's own console, 
>>> but that is not ideal, because 1) other Leo output may get mixed in with 
>>> the external program's or the output may get scrolled offscreen; 2) if the 
>>> external program crashes, it may leave your Leo console running a secondary 
>>> shell; and 3) if you launch a GUI program that lasts a long time your 
>>> output may get very confusing.
>>>
>>> It turns out that to reliably keep the new terminal open on Linux, you 
>>> have to open a terminal and use that to run the shell, not just launch the 
>>> shell.  This is a problem because there are a lot of Linux distros and they 
>>> don't all have the same terminal.  In particular, the different terminals 
>>> don't always use the same options to run a shell with its command line.  
>>> The shell may also differ.  Almost all desktops use bash, usually at 
>>> /usr/bin/bash, but a user can change that and some do.
>>>
>>> So we can't assume that the shell will be bash, nor what the terminal 
>>> may be.  x-terminal-emulator does not give you the same options across 
>>> distros, either.  $TERM doesn't actually give you the terminal either, just 
>>> a logical terminal so the right colors can be set up. 
>>>
>>> To keep the terminal open after the command runs, some terminals have an 
>>> option for that, some have the option but it doesn't work, and some don't 
>>> have the option. Also, the option name is subject to change (I found at 
>>> least one distro that issued a deprecation warning) So we need another 
>>> solution.  My solution is to have the shell wait for user input after the 
>>> main command finishes.  After a long time running queries on the Internet I 
>>> have not found a more workable way.
>>>
>>> So how do we find the terminal and shell?  By running pstree -s $$ and 
>>> parsing its output.  Then we run that terminal with --help and try to 
>>> parse the help message to find the right option.  This works on all cases 
>>> I've tried, but it's probably a little fragile.
>>>
>>> If the shell isn't bash, or we can't figure it out, we use the $SHELL 
>>> variable.
>>>
>>> Then we use the command's internal table, or the system file 
>>> association, to find the right processor to run.  We also check to make 
>>> sure it can actually be found.
>>>
>>> Finally we can construct the command and run it.  Whew, that was 
>>> tricky!  It's easier on Windows because we don't have to discover the 
>>> terminal and shell, and the launch options are always the same.
>>>
>>> For the Mac, I don't know the terminal or shell names nor the right 
>>> options to invoke.  I'm pretty sure that if I learn them this command will 
>>> work on a Mac too.
>>>
>>>

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/d0f178bb-6e70-4e52-8c2e-05a2bd95287fn%40googlegroups.com.

Reply via email to