Re: [Help-bash] Option execfail does not work in subshells

[R. Diez]

> If you don't mind my asking, why are you having a user pass commands in 
> the first place? That's an excellent way to be rather insecure.


I regularly use the following script I wrote to let me know when 
low-priority, "background" processes (like a long compilation) finish:

https://github.com/rdiez/Tools/tree/master/Background

The script lets you specify a command that you want to run, and it runs 
it with low priority, redirecting its output to log files that are 
(more-or-less) automatically rotated over time.

I am considering enhancing the script. If the user does not need a 
notification at the end, I could use 'exec' to replace the script with 
the user's process.

But I have a more important reason now. I recently asked the following 
question on this mailing list:

Automatically "disown -h" all background jobs
https://lists.gnu.org/archive/html/help-bash/2017-08/msg00000.html

I am investigating whether it is possibly to write a similar helper 
script that starts any GUI command in the background, detached from the 
console. I think that blocking SIGHUP, like nohup does, may not be 
necessary. The helper script should redirect stdout and stderr to 
automatically-rotated log files.

The main problem I am facing is that, if you type something like 
"StartDetached.sh mycommand", and 'mycommand' does not exist, the error 
message goes to the redirected stderr, which is not very user friendly. 
I am investigating how much comfortable error detection and reporting is 
possible with Bash/Linux in this scenario.

Tool 'nohup' does try to report any error that 'exec' reports. It may 
not be possible to do more, but at least you get an error message if the 
command does not exist at all. I thought I could do the same with Bash, 
but then I hit the execfail problem I reported.

Regards,
  rdiez