In a test case such as tcli user password set portal IDoNotExist IDoNotExist, and in a case where that user does not exist in the system, the tcli software correctly outputs the following feedback:
An error occured: No entry in member with that ID.
However, this is not a successful execution of the program. Yet, it returns a 0 code, which it should not.
Another example, but with logins:
$ tcli system login foo bar
An error occured: Login incorrect.
This is also not a successful execution of the program. It also returns a 0 code, which it should not.
In a command line environment, especially if we're scripting the password resets in, say, Python, and using calls to the executable via the subprocess module, checking the error codes is a critical part to determining if a command failed. Any process that fails should return a non-zero exit code. Such failed processes will, when a subprocess.run(..., check=True) call or a subprocess.check_output(...) call is made, will have a non-zero exit code and in turn cause subprocess to raise a CalledProcessError which indicates that there was a failure in the command's execution (and includes a lot more data in the error as to what error code happened, where it died, stderr output, etc.).
As I have to do password sets in batches due to a known issue (of which @bapril is aware), having to iterate over a whole list of users is vital to properly setting those passwords. However, if I can't properly determine whether the command executed successfully or not with the returned execution code, this can prevent scripts operating reliably.
Please update the tcli command line utility when executed on an SSH shell so that if it has an error case during execution, it returns a non-zero exit code, so scripts properly behave when checking the return code for the executable process.
In a test case such as
tcli user password set portal IDoNotExist IDoNotExist, and in a case where that user does not exist in the system, thetclisoftware correctly outputs the following feedback:However, this is not a successful execution of the program. Yet, it returns a
0code, which it should not.Another example, but with logins:
This is also not a successful execution of the program. It also returns a
0code, which it should not.In a command line environment, especially if we're scripting the password resets in, say, Python, and using calls to the executable via the
subprocessmodule, checking the error codes is a critical part to determining if a command failed. Any process that fails should return a non-zero exit code. Such failed processes will, when asubprocess.run(..., check=True)call or asubprocess.check_output(...)call is made, will have a non-zero exit code and in turn causesubprocessto raise aCalledProcessErrorwhich indicates that there was a failure in the command's execution (and includes a lot more data in the error as to what error code happened, where it died,stderroutput, etc.).As I have to do password sets in batches due to a known issue (of which @bapril is aware), having to iterate over a whole list of users is vital to properly setting those passwords. However, if I can't properly determine whether the command executed successfully or not with the returned execution code, this can prevent scripts operating reliably.
Please update the
tclicommand line utility when executed on an SSH shell so that if it has an error case during execution, it returns a non-zero exit code, so scripts properly behave when checking the return code for the executable process.