Disclaimer: I know enough bash script to be dangerous but not enough to figure out my issue.

I took a DMenu script from Manjaro to run on my Ubuntu 20.04 machine. The script lets the user select a program and if it is the first time a program is ran it ask if it should be ran in the background, a terminal, or a terminal held open. The script The DMenu version runs fine.

I also modified it to use fzf in place of DMenu.

The script runs fine when called from the command line.

A new terminal window opens with the fzf options, one a program is selected, the program starts and is disowned so when the menu window closes the selected program still continues.

If I call the program from a hot key using A uxterm window opens the fzf menu comes up but when I select the program it will start but the is ignored and once the menu closes so does the program.

I am sure the issue is my incorrect understand of how shells work. If anyone could point me to some resources so I can understand what is going on that would be great?

The code I am working on is at https://github.com/frrobert2/I3DMenuMods

Thanks

I would try it within a shell:

That way the redirect and disown get applied to fzf_recency.

There might be another way, but that's what I'd try first.

This is almost impossible without debugging....
But anyway this line is just wrong. Either you use exec or disown. Both of them cannot work together, because exec $cmd will never return (only in case of an error).
see man bash, exec replaces the current shell, it will not exist any more (the shell script).

pan64,

Thank you for your help. I still have not fixed my issue but I think I'm learning.

Here is a more detailed question.

If a shell script is called by uxrt -e myscript and myscript spawns a child process how can write the parent script so that it disowns the child process or is it even possible?


Below is what I have tried so far and the results
[[ "$type" = "background" ]] && $cmd
program called by $cmd opens both windows stay open

I also tried above with $cmd being the program plus &>/dev/null & disown that did not work either. It appeared the script saw the &>/dev/null & disown as program arguments and not bash. If that makes sense.

[[ "$type" = "background" ]] && exec $cmd
program called by $cmd opens both windows stay open

[[ "$type" = "background" ]] && nohup $cmd &
program called by $cmd will start but closes as soon as menu window closes when called by hot key works as desired if script called from command line

[[ "$type" = "background" ]] && $cmd &>/dev/null & disown
program called by $cmd will start but closes as soon as menu window closes when called by hot key
program called by $cmd will start but closes as soon as menu window closes when called by hot key works as desired if script called from command line


Thanks

See this thread and my comments.

Thanks to everyone for there help but I think maybe there is some confusion of what I am asking. I am sorry for any confusion

Here is a simple bash program that the illustrates the issue and some things I have tried after your suggestions:

Simple script that opens gimp. I have five different options to try to disown the process

I simply run testdisown 1 to use the first option and so on for each option

If I run the shell script from a command prompt all options start gimp and gimp is not attached to the shell so if I close the terminal emulator gimp is still running.

If I run the same script from a hot key such as Alt+F2 using uxterm -e testdisown 1 and so on for each option
each option starts gimp but when the first window closes gimp also closes.

The behavior I want is the same as I am getting from running it from the command prompt but using a hot key.

Thanks

Try:

if you want to run gimp, do not run uxterm, but gimp directly.

Thanks but it works just as the same as the first five. Works when you run the program from the shell prompt but when you run it from the hotkey it gimp closes when the first window closes.

There must be something about that makes the script function differently then when ran from the command line.

Since the actual script I am working on is a fzf version of dmenu in i3.
I came up with this work around for now.

When I fire up i3 it creates a floating terminal window called FZFMENU and puts it into the scratchpad. I set the hotkey to toggle the menu window between the current workspace and scratchpad. The first time I pull up the window it is just plain terminal emulator window.

I added a infinite loop to the script and a command to place the script back in the scratchpad. So the first time I pull up the menu I need to run the script. But from then on the menu reloads after it starts the program and since I started the script from the command line the glitch is not there.

Not perfect but it works until I can figure a way to autostart the script.

Thanks again

pan64 the script I posted this morning is just a simple example script to show where the glitch rather than posting a link to the full menu script.

if I understand it well it is a tty related problem, when you close the terminal gimp will die too, because tty is lost. Would be nice to see if there was any message printed by gimp, so instead of &>/dev/null you can redirect output into a file and check...

Here is the log file:

(gimp:96232): Gtk-WARNING **: 21:16:16.218: Unable to locate theme engine in module_path: "pixmap",
/usr/lib/gimp/2.0/plug-ins/script-fu/script-fu terminated: Hangup
gimp: terminated: Hangup
/usr/lib/gimp/2.0/plug-ins/script-fu/script-fu terminated: Hangup
gimp: terminated: Hangup

The writer of fzf uses this script to work around the problem. I encourage you to look at it, how it uses the fifo to achieve what is desired.
Attempts to rewrite the script have failed in this thread (there is one extremely hackish "solution" towards the end, I'm not surprised it doesn't work as expected).

The solution is to call the original script as provided from another script that does what you want (it is not necessary to use st however, you can change that bit to another terminal emulator).

onodoho,

Thanks for the information.

The post has some things I have not used before so it may be a few days before I get the actual solution.

The key seems to be calling the terminal for fzf from within the script rather than running the script from uxterm -e myscript

Once I figure I the solution I will post it.

Thanks everyone for their help.

I don't know if disown is needed but you should also redirect stdin