Timeline for How to "correctly" start an application from a shell
Current License: CC BY-SA 3.0
18 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Mar 4, 2024 at 5:18 | comment | added | G-Man Says 'Reinstate Monica' | See also Difference between nohup, disown and &. | |
| Apr 9, 2018 at 17:36 | answer | added | jwm | timeline score: 11 | |
| Aug 25, 2016 at 17:30 | answer | added | gnucchi | timeline score: 24 | |
| Sep 1, 2014 at 15:23 | vote | accept | lord.garbage | ||
| Aug 27, 2014 at 21:05 | comment | added | Barmar | What you call a shell independent process is usually called a background process. Putting & at the end of the command simply tells the shell not to wait for the command to finish. It's still a child of the current shell, and you can use fg to move it to the foreground. Job control also usually prevents background processes from reading input from the terminal. | |
| Aug 27, 2014 at 13:30 | comment | added | lord.garbage | Maybe a simpler question for now is: How is it possible to get the above process tree from the shell: systemd--bash--chromium. All methods I try will ultimately lead to a process tree of the following form systemd--chromium when I spawn firefox from the shell. How is the shell demonized here? It is not associated with any terminal. | |
| Aug 27, 2014 at 2:45 | history | edited | lord.garbage | CC BY-SA 3.0 | added 4183 characters in body |
| Aug 27, 2014 at 2:44 | comment | added | mikeserv | @lord.garbage - that's because you exec &, I think. I usually just do my stuff from the terminal... maybe you'd get some use out of ben crowell's question here. I have an answer there, but all of them are very good. anyway, when you background a process and its parent dies like: sh -c 'cat & kill $$' you orphan it, and it winds up getting reaped eventually. that's init's job - that's why they all fall to it. | |
| Aug 27, 2014 at 2:36 | comment | added | lord.garbage | Hahaha, cheers @mikeserv; 4:37 am in the morning here and already the first laugh of the day. True, that stuff always somehow works out. I will remove dmenu and see how I get along with what I learned. I find exec /path/to/Program & exit or /bin/bash -c /path/to/Program & exit to be quite usable. But they all make 1 i.e. init the parent of the Program which is fine with me as long as this makes sense and does not violate any basic *nix principles. | |
| Aug 27, 2014 at 2:29 | comment | added | mikeserv | dang, garbage - you ask some good questions. but I think wayne's on the nose here - your latest edit asks about init - to which the answer might be... maybe? it depends on how/if you plan to talk to it, what init you use, and where the data channels are. In general that stuff will tend to work itself out - that's what init is for. In any case, usually when you daemonize a process then init. Or if you want job control, current shell. | |
| Aug 27, 2014 at 2:24 | history | edited | lord.garbage | CC BY-SA 3.0 | added 242 characters in body |
| Aug 27, 2014 at 2:12 | comment | added | Wayne Werner | The terse answer to your question would be "whatever gets the results you want." | |
| Aug 27, 2014 at 2:00 | history | tweeted | twitter.com/#!/StackUnix/status/504448273114206208 | ||
| Aug 26, 2014 at 22:38 | history | edited | lord.garbage | CC BY-SA 3.0 | added 565 characters in body |
| Aug 26, 2014 at 22:16 | answer | added | G-Man Says 'Reinstate Monica' | timeline score: 10 | |
| Aug 26, 2014 at 22:01 | history | edited | lord.garbage | CC BY-SA 3.0 | added another launch method |
| Aug 26, 2014 at 21:52 | history | edited | Braiam | edited tags | |
| Aug 26, 2014 at 21:42 | history | asked | lord.garbage | CC BY-SA 3.0 |