(Non-)Feature-Request: Keep it simple

[dreua]

Since mercury is meant to be used mainly by unix-users, I think it should stick to the Unix Philosophy and apply the KISS principle. (If I were to develop this app I would even consider removing the "nohup" and "sudo" options in favor of a simpler, more intuitive and more secure app. Every administrator can add nohup and sudo to his or her scripts and adding the needed commands to the sudoers file is much better than storing and transmitting passwords for sudo on your Android device.)

[Skarafaz]

Without nohup this app does not work; the channel is closed as soon as the command is sent, so if you don't use nohup the process is killed.

Mercury does not store passwords; if you do not want to put the password into your config file, you can just type it each time you send a "sudo" command. I know that sudo can be massively configured to do a lot of interesting things, but this app is designed to work out of the box without (too much) server side configuration.

[dreua]

Yeah, I guess using nohup was the simplest approach in the first place, but you can't get the output with nohup and so it might be a better idea to close the channel after a reasonable timeout (if you just want to send a wake on lan packet or get the "uptime" it acutally works by just removing the nohup, I didn't add or increase a timeout)

Additionally, I had a bigger problem with nohup since the Wlan router I wanted to use to send WOL-packets did't have nohup and it wasn't easy to track down the issue and find a workaround for it. - Maybe most users are happy with nohup by default but some are not and I just wanted to make you aware of it ;)

[Skarafaz]

but you can't get the output with nohup

This is a design choice; Mercury sends commands asynchronously, synchronous execution and output handling will be added soon.

and so it might be a better idea to close the channel after a reasonable timeout

Without nohup, killing the session means killing the process; you can't predict the execution time of a command.

if you just want to send a wake on lan packet or get the "uptime" it acutally works by just removing the nohup

It works just for short-lived commands.

the Wlan router I wanted to use to send WOL-packets did't have nohup

At the moment nohup is a minimum requirement; it will become a recommended requirement (for the asynchronous mode only) as soon as the synchronous mode is implemented.

it wasn't easy to track down the issue

Yes, this is the worst drawback of the design choice mentioned above; this problem will be solved by the upcoming synchronous execution mode.

[dreua]

Allright, I'm looking forward to see the new version. And I appreciate your work! :+1:

[Skarafaz]

Thank you @dreua !