I agree w/ atom and you that stdout/stderr reading isn't a good choice in general and should be avoided whenever possible but I think that w/o a full API access to *hashcats functionalities, this is the only way to go for now.
Since it is very easy to validate and parse the "status output" of *hashcat this isn't as evil as one may think.
Of course there will be some edge cases and you must validate the values/strings you get, but by validating each of this fields you should be able to get whatever you need.
If you really think this isn't doable, then please make a list of disadvantages of this stdout/stderr reading (beside the stdout "noise" argument) and a suggestion how a better solution should look like and how it should be implemented by @atom.
I think atom may be willing to accept a feature request for adding some "API queries" e.g. via custom SIGNALS etc which trigger a write to a file whenever a signal is catched etc etc. IFF atom thinks this is of use also to other users and IFF the suggested format is struct(ured) well.
I think some suggestions are always welcome.
Furthermore, I may not be the right person who has enough knowledge if *hashcat may not have other means to get some speed etc info (which are/can be written to some other files etc).
BTW: I don't think that one can generally argue that reading a file is much better than reading from a pipe, it only depends what the format of the "output" is and if it is somehow standard (and doesn't include "noise")... For instance, the stdout may include cracked passwords, instead .restore doesn't include that for sure (but it also misses e.g. speed), but the pot file does etc etc.
Since it is very easy to validate and parse the "status output" of *hashcat this isn't as evil as one may think.
Of course there will be some edge cases and you must validate the values/strings you get, but by validating each of this fields you should be able to get whatever you need.
If you really think this isn't doable, then please make a list of disadvantages of this stdout/stderr reading (beside the stdout "noise" argument) and a suggestion how a better solution should look like and how it should be implemented by @atom.
I think atom may be willing to accept a feature request for adding some "API queries" e.g. via custom SIGNALS etc which trigger a write to a file whenever a signal is catched etc etc. IFF atom thinks this is of use also to other users and IFF the suggested format is struct(ured) well.
I think some suggestions are always welcome.
Furthermore, I may not be the right person who has enough knowledge if *hashcat may not have other means to get some speed etc info (which are/can be written to some other files etc).
BTW: I don't think that one can generally argue that reading a file is much better than reading from a pipe, it only depends what the format of the "output" is and if it is somehow standard (and doesn't include "noise")... For instance, the stdout may include cracked passwords, instead .restore doesn't include that for sure (but it also misses e.g. speed), but the pot file does etc etc.