Thanks, I'd appreciate it. On Sunday, February 19, 2023 at 12:38:04 PM UTC-5 jkn wrote:
> 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/91a89a82-2330-4a62-a817-6ce503ea8906n%40googlegroups.com.
