Requesting new return codes for `op get item`

HippoMan

It would be helpful if op get item would return different return codes between the cases where the item doesn't exist, and the cases where multiple items exist.

For example, assume that I have only two items in my Personal folder, and both are named testnote ...

% op get item testnote; echo rc=$?
[LOG] 2018/05/30 12:08:54 (ERROR) multiple items found with query "testnote", please choose one of the following matches: 
    for the item testnote in vault Personal, run `op get item l2od5pfrhutheqwkn5uoh53wxa`
    for the item testnote in vault Personal, run `op get item w2cdw2rkqdeixetvk6uoqtiw7m`
rc=1
%  op get item nonexistent; echo rc=$?
[LOG] 2018/05/30 12:09:44 (ERROR) item nonexistent not found
rc=1

It would be nice if we get different return codes in these cases, so scripts that make op get item calls don't have to parse the text that is returned in order to understand what happened.

I suggest that in the first case, the return code should be the number of matching items. In my example, it would be 2.
In the second case, I suggest that -1 be the return code, so that it is distinguishable from other unrelated errors that would normally return a code of 1.

---

1Password Version: Not Provided
Extension Version: Not Provided
OS Version: Not Provided
Sync Type: Not Provided

HippoMan

Here's a script I wrote called op-item-exists, which does all of this messy and less-than-desirable string parsing of the op get item output.

#!/bin/zsh -f

prog=${0##*/}
op=/usr/local/bin/op
egrep=/bin/egrep
wc=/usr/bin/wc
tmp=/tmp/.${prog}.$$

quit() {
  /bin/rm -f ${tmp}
  exit ${1}
}

trap 'quit 1' 1 2 3 15

verbose=
while getopts :vV o
do
  case "${o}" in
  ([vV])
    verbose=t
    ;;
  (*)
    print -r -- "${0##*/}: invalid option: -${o}"
    exit 1
    ;;
  esac
done

shift $(( ${OPTIND} - 1 ))

[[ $# -lt 1 ]] && {
  print - "
usage: ${prog} [ -vV ] item [ optional 'op get item' arguments ]

  where -v,-V gives verbose output

  returns  0 if the item exists,
           N if it finds N (> 1) matched items,
          -1 if the item doesn't exist,
           1 in all other cases

  optional arguments could contain '--vault=XXX', for example
"
  quit -2
}

item="${1}"
shift

${op} get item "${item}" "${@}" 1>${tmp} 2>&1
rc=$?

if [[ ${rc} -eq 0 ]]
then
  [[ -n "${verbose:-}" ]] && print "item found: ${item}"
  quit 0
elif ${egrep} -q '\(ERROR\) +multiple +items' ${tmp}
then
  (( rc = $(${wc} -l <${tmp}) - 1 ))
  [[ -n "${verbose:-}" ]] && print "${rc} items found: ${item}"
  quit ${rc}
elif ${egrep} -q '\(ERROR\) +item .+ not +found' ${tmp}
then
  [[ -n "${verbose:-}" ]] && print "not found: ${item}"
  quit -1
else
  [[ -n "${verbose:-}" ]] && /bin/cat "${tmp}"
  quit ${rc}
fi

quit 0

cohix

That's a good idea @HippoMan. I've been contemplating the best way to do this for a while. I will need to look over every scenario where it makes sense to do this (because there are some where it is not appropriate).

HippoMan

Understood. I'll be happy as long as there is some way via return codes to tell the difference between (1) item not found; (2) multiple items found; (3) some other unrelated error.

cohix

Gotcha. We could theoretically do what you suggested for those cases, and use the HTTP error code if something else random happens.

I'll talk to the team about it.

HippoMan

Thank you!

Just a point about HTTP error codes: they usually are higher than 127, but program return codes are only valid to 8 bits, with the high-order bit having special meaning,

cohix

Good point, I'll keep that in mind.