Thanks for the suggestion andi_t_1P . While that does work and I can turn a JSON document into that format, it's less than desirable to use yet another format for structured data when JSON already works just fine. Working with more than one field through scripting is very cumbersome, as one needs not only to format the data in those url-encoded-ish key value pairs, but also find a way to properly read potentially multi-line values in order to feed them into op item edit programatically.

All doable, of course, but terribly annoying in my opinion; here's an example of how I went about it:

```jq

we start with a jq function that looks like:

it takes a list of fields (i.e. .fields[])

def fields_to_cli($delete_field_names; $separator):
# section.field.name=value
map(
(.section.id // "") + (if .section then "." else "" end) + (.label | gsub("\."; "\."))+
"["+(if .purpose == "PASSWORD" then "password" else "text" end)+"]="+.value
) +
($delete_field_names | map((.| gsub("\."; "\."))+"[delete]=")) |
sort |
join($separator);
```

```bash
function deleted_fields_from() {
# imaginary function that returns a json list of fields present in a
# 1password item that were removed from a correspondingly named file
# in the local filesystem
jq -s \
'((.[1].fields | map(.id)) - (.[0].fields | map(.id)))' \
"$1" <(op item get "${1%.json}")
}

first, get the item

op item get "top-secret" > top-secret.json

then edit the downloaded file

jq ...

then figure out which fields were deleted

deleted="$(deleted_fields_from "top-secret.json")"

then pick a boundary/separator character (¬)

and hope there's no values or keys that use it

every value, delimited by that separator will be read

as an item of the args array

IFS='¬' read -ra args < <(
jq \
--arg separator '¬'
--jsonarg delete_field_names "$deleted" \
'fields_to_cli($delete_field_names; $separator)'
"top-secret.json")

finally, expand that array, and hope the parser for op item edit doesn't change.

op item edit "top-secret" -- "${args[@]}"
```

compare that to

bash
op item get "top-secret" | jq 'some fiter' | op item edit "top-secret"


Latter is more desirable in my opinion, and would love to see straight-from-json updating in op at some point in the future. At the very least, I'd expect invoking op item edit without any key-value pairs should result in an error or warning, instead of it increasing the version.