Requesting new return codes for `op get item`

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`
%  op get item nonexistent; echo rc=$?
[LOG] 2018/05/30 12:09:44 (ERROR) item nonexistent not found

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


  • HippoManHippoMan
    edited May 2018

    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
    quit() {
      /bin/rm -f ${tmp}
      exit ${1}
    trap 'quit 1' 1 2 3 15
    while getopts :vV o
      case "${o}" in
        print -r -- "${0##*/}: invalid option: -${o}"
        exit 1
    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
    ${op} get item "${item}" "${@}" 1>${tmp} 2>&1
    if [[ ${rc} -eq 0 ]]
      [[ -n "${verbose:-}" ]] && print "item found: ${item}"
      quit 0
    elif ${egrep} -q '\(ERROR\) +multiple +items' ${tmp}
      (( rc = $(${wc} -l <${tmp}) - 1 ))
      [[ -n "${verbose:-}" ]] && print "${rc} items found: ${item}"
      quit ${rc}
    elif ${egrep} -q '\(ERROR\) +item .+ not +found' ${tmp}
      [[ -n "${verbose:-}" ]] && print "not found: ${item}"
      quit -1
      [[ -n "${verbose:-}" ]] && /bin/cat "${tmp}"
      quit ${rc}
    quit 0
  • cohixcohix

    Team Member

    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).

  • 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.

  • cohixcohix

    Team Member

    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.

  • HippoManHippoMan
    edited May 2018

    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,

  • cohixcohix

    Team Member

    Good point, I'll keep that in mind.

This discussion has been closed.