Improve "rbw get" search

[GRbit]

When I search for an entry, sometimes I want a better search matching. For example, when I use two words in search, rbw interprets it as an email, so I need to change query. Like this:

[0] $ rbw get Company gmail
rbw get: couldn't find entry for 'gmail@Company': no entry found
[1] $ rbw get 'Company gmail'
TOP_SECRET_PASSWORD
[0] $

It would be great to not only add a fallback in case "nothing was found", but maybe also try to implement other search improvements. My first suggestion — if all letters in a request are lowercase, then make the search case insensitive. The next step could be a "non-strict search" which allows typos (only if nothing was found with the original request).

@doy can you share your thought on this? Which improvements you'd like to see in PR's, and which would be too much?

[doy]

i think i would prefer for rbw get to continue working the way it does currently, because having a consistent way to find specific entries is useful. i wouldn't be opposed to a new keyword (rbw search or whatever) that implemented more complicated behavior, though.

[GRbit]

Totally agree with your thoughts on consistency. I hat myself when the tool I use behave in a different way after the update. My mistake was that I would imagine some one relies on "nothing was found" behavior.
Ne search command indeed looks like a better solution.

P.S.: I still don't quite follow the way it works with two words. Could you maybe explain the logic?

[doy]

the syntax is rbw get NAME USER, so in your example, it is looking for an password entry named Company where the username is gmail. using quotes like in your second example is the correct way to retrieve entries where the name includes spaces.

[dgmcdona]

@GRbit One thing to consider may be to pair it with something like fzf:

passwd() {
  rbw unlock && rbw get "$(rbw list | fzf)"
}

Edited to add unlock command

[GRbit]

@dgmcdona that's f*cking brilliant!

With this I think I'd rather close the issue. That works like a charm.

[dgmcdona]

Glad it works for you! I realized after posting that it helps if you also prefix that with a call to rbw unlock so things don't get funky if the vault hasn't been unlocked yet.

[synnack]

Based on @dgmcdona's script I made a slight modification to allow get --raw, --field xxx and --full as parameters (as I need --raw or --field PIN to get custom field PIN for bank cards). And I like to search in folder names as well :)

rbwsearch() {
	SEARCH_ARGS=()
	RBW_ARGS=()

	while [[ $# -gt 0 ]]; do
		case $1 in
		-f|--field)
			RBW_ARGS+=("$1" "$2")
			shift
			shift
			;;
		-*)
			RBW_ARGS+=("$1")
			shift
			;;
		*)
			SEARCH_ARGS+=("$1")
			shift
			;;
		esac
	done
	rbw unlock || return
	IFS=$'\t' read -r NAME FOLDER < <(rbw list --fields name,folder|fzf -q "${SEARCH_ARGS[*]}")
	if [ -n "$FOLDER" ]; then
		RBW_ARGS+=("--folder" "$FOLDER")
	fi
	rbw get "${RBW_ARGS[@]}" "$NAME"
}

[sedlund]

rbw unlocked execs ~twice as fast as unlock tested with hyperfine. Suggest using rbw unlocked || rbw unlock

[bugabinga]

I have a note in my Bitwarden Vault, that has as its name a UUID (eg bc0b722f-9aa0-4aad-badc-d0e94bbd981a). It also happens to be in a folder.

rbw search can find the note, but rbw get fails to retrieve it:

rbw get: couldn't find entry for 'bc0b722f-9aa0-4aad-badc-d0e94bbd981a': no entry found

Other notes in that folder can be normally retrieved.

New issue or expected behaviour?