Submitted by yngens on Mon, 10/15/2018 - 00:40
Consider you've composed a custom command on Webmin > Others > Custom commands to restart a service on the system. If you click on the button simulating error on the service, then it correctly gives:
Output from command .. Job for custom.service failed because the control process exited with error code. See "systemctl status custom.service" and "journalctl -xe" for details.
However, if you eliminate the error simulation and let it execute successfully, then the output looks like:
Output from command .. No output generated
which is technically correct, because there would be empty output if it was executed on CLI, however it doesn't look nice from the end-user perspective. It would be more user-friendly if Webmin replaced that message with something like: Command executed successfully.
Thanks for considerations.
P.S. Also please consider removing the Output from command ..
part as it is obvious it is an output form command.
Status:
Closed (fixed)
Comments
For the P.S., you can make a copy of the Custom Commands module in the Webmin Modules page, change the module.info to have the module named "custom2" or "mycustom" or something, and then edit the
lang/en
file to have it say whatever you like (or nothing), just search for the line you want to change (you could do it directly in the module itself, but it'd be overwritten on each Webmin update...a copy will remain untouched). It's pretty arbitrary what it says on output, and I don't think the current language is bad or unclear.For the successful result output, I don't think I'd want to change the output if the command succeeds and has output of its own. But, I guess if there is no output (which we're already detecting) and there is no error, we can print a "success" message. Hopefully everybody's custom commands actually return an error if they fail (a lot of people use the Custom Commands module to call out to scripts that do custom stuff...not everyone knows how to return non-zero values on error, but hopefully it would print some kind of error output, and our "success" wouldn't show, even if they don't set a non-zero return value).
OK, I dug into the code, thinking I could make a couple lines worth of changes to implement it, but it's actually a pretty big set of changes touching at least two modules (proc and custom), as we're not currently catching the return code, just the output of the command. Next time I talk to Jamie, I'll see if I'm missing a function to capture both, but it looks like far-reaching enough changes that it's not something that can be done in much less than a couple of hours, especially since this is security sensitive code.
So, the way to get what you want right now would be to use a wrapper script that outputs whatever you like; could be in any language, but shell would work fine and only be a few lines of code.
Something like (untested, but should be pretty close):
#!/bin/sh
command=$1
res=$($command)
if [ $? -ne 0 ]; then
echo "Error!"
else
echo "Success!"
fi
echo $res
exit 0
If you called that script "run_wrapper.sh" and put it in the path (like
/usr/local/bin
, probably), you'd then call it from Custom Commands with something likerun_wrapper.sh "ls -l /home/joe"
(note the arguments need to be quoted, or they'll end up in multiple variables when parsed into $command). This might actually be pretty tricky, as shell arguments are tricky...definitely needs testing and maybe tweaking. I'm a little rusty on running commands in bash/shell as I wrote a function for it in my shell library that I use for the installer and then forgot all about it. You could use any language you like for the wrapper script, but most other than maybe Perl would result in a few extra lines of code and a bit more verbosity, just because most aren't really tuned to being used for running commands like a shell scripting language. It just needs to be able to execute code using the environment provided to it and capture return values and then print them to standard out.If you really don't want to do it with a wrapper script and need it implemented within Webmin itself, we can do it under contract at our usual hourly rate ($125/hr). It's about an hour and a half of work, I think, including testing.
Submitted by yngens on Tue, 10/16/2018 - 00:34 Comment #3
Fair enough. It's not essential to us, just wanted to enhance min's usability a bit. Nevermind.
I'll probably get around to it, eventually, as it would be nice to have the exit code checked, but since this is the first time it's come up in 20 years as far as I know, I guess it's not urgently impacting most folks. ;-)
Submitted by JamieCameron on Tue, 10/16/2018 - 17:56 Comment #5
I took a look at this, and actually there's no good reason not to show if a custom command failed. I will add this in the next release.
Submitted by IssueBot on Thu, 02/28/2019 - 09:07 Comment #6
Automatically closed - issue fixed for 2 weeks with no activity.