I upgraded from 2.0 to 2.5 of the CLI this week and it broke the iTerm2 integration. The issue seems to be that the CLI really cares about whether stdin is a tty or not.
These commands fail to open a biometric auth window when stdin is not a TTY and simply seem to hang:
While this command doesn't work at all when stdin is a TTY:
For some reason I don't understand, I can't reproduce this from a regular shell (.e.g,
op user get --me < /dev/null does show an auth window) but when my Cocoa app forks & execs
op user get --me with a pipe for file descriptor 0 it does hang, while giving it the slave side of a pseudoterminal doesn't hang.
Is this intentional? I'm a little worried that I may have missed some cases where the TTYness of fd 0 is wrong. It would be nice if op didn't care so much about this.
If there's a good reason for requiring a TTY in general, it would be nice if if providing a TTY didn't break anything. I don't see a good reason why
op item get --format=json --no-color - should fail with a TTY, and the error it gives is not great:
[ERROR] 2022/07/06 23:28:40 "-" isn't an item. Specify the item with its UUID, name, or domain.
1Password Version: 8.8.0
Extension Version: Not Provided
OS Version: macOS 12.4
Browser:_ Not Provided