Alerta CLI Silent Exit about python-alerta-client

[mmulqueen]

@satterly This seems to work for me now. The weird thing is that the new environmental variables you're checking are unset, but equally the problem has gone away with the latest version on git. So I think this may have created a new bug, which has accidentally masked the old bug for me.

I think your new if statement may not evaluate what you intended.

The current code is:

if not sys.stdin.isatty() and (os.environ.get('TERM', None) or os.environ.get('PS1', None)):

I read this as: It's not a TTY and it either TERM or PS1 is truthy.

not has a higher priority than and in Python. So if I put in some more brackets to clarify the order:

if (not sys.stdin.isatty()) and (os.environ.get('TERM', None) or os.environ.get('PS1', None)):

I think you were aiming for: It's not a tty and neither TERM or PS1 is truthy, which would be:

if not sys.stdin.isatty() and not (os.environ.get('TERM', None) or os.environ.get('PS1', None)):

Or equally and perhaps clearer:

if not (sys.stin.isatty() or os.environ.get('TERM', None) or os.environ.get('PS1', None)):

I'm not sure whether I've got the wrong end of the stick or not here. If I'm on the right lines, then by fixing this new bug, the old bug will reappear.

I'd like to suggest that the piping behaviour be disabled by default and enabled by it's own CLI option (e.g. --pipe-input json_lines). It looks like it's almost impossible to tell the difference between a job running a cron environment and a pipe.

[satterly]

not only applies to the first test (ie. the isatty() check) otherwise both these statements would give the same result...

>>> not True and False
False
>>> not (True and False)
True

What I'm checking for is ...

IF it does not have a TTY
    THEN it is either cron or data is being piped to stdin
    IF it is a terminal (ie. is `TERM` or `PS1` set?)
        THEN read data from stdin
ELSE
    assume it is a terminal console, or cron, and run send with command-line args

So I'm pretty sure this change works as intended but let me know if this still doesn't make sense.

[mmulqueen]

@satterly My mistake. Fully understand why you've done this and how it works now. Bug indeed fixed and there is no new bug. Sorry about the false alarm!

[satterly]

No problem. It was good to clarify, in my own head, what was going on just to be sure.