Requesting new return codes for `op get item`

HippoMan
HippoMan
Community Member

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

Comments

  • HippoMan
    HippoMan
    Community Member
    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
    
    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
    cohix
    1Password Alumni

    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
    HippoMan
    Community Member

    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
    cohix
    1Password Alumni

    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
    HippoMan
    Community Member
    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,

  • cohix
    cohix
    1Password Alumni

    Good point, I'll keep that in mind.

This discussion has been closed.