I found a temporary fix op item get .env.local2 --fields notesPlain | xargs echo

Edit:
When you have something in the note like:
NEXT_PUBLIC_ENV="DEV"
NEXT_PUBLIC_API_HOST="http://localhost:8000"

Then the xargs trick doesn't work.

However this does work:
op item get .env.local --fields notesPlain --format json | jq '.value' -r

Hey @raybb , thank you for reaching out to us!
I was able to reproduce this, it seems to be indeed a bug. I've filed an internal issue and will take it up with the team during our next team meeting.
In the meantime, there is a new command in CLIv2 that allows you retrieving field values in a more native fashion: op read. Did you already get to give it a try? Running op read op://<vault name or ID>/<item name or ID>/notesPlain should retrieve the correct value.
Let us know if this is helpful for you!
Best,
Horia

Hi, would be great to have that fixed.

Read is fine but we're loading the whole item and then extract some fields which currently breaks.

We're currently working on this issue, we should be able to push out a fix for this in the next release.
I'll post a comment in the thread once this gets resolved. Thank you once again for reporting!

Hey @raybb @franklin

We believe that you can achieve the same output behaviour possible with V1 with V2:

Getting the raw value of a single field

v1

op get item <item> --fields <field>

v2

op read op://<vault>/<item>/<field>

Getting multiple values in the csv format

v1

op get item <item> --fields <field1>,<field2> --format csv

v2

op item get <item> --fields <field1>,<field2>

Getting values in the json format

v1

op get item <item> --fields <field>

v2

op item get <item> --fields <field>

That being said, we do recognize that the current behaviour may not be what you are looking for and are interested in learning more about your use cases to see where we can improve.

Could you tell us a bit more about your workflow? Where are you using the values from 1Password? Are you doing manual commands or feeding the output into a script or another workflow?

@raybb The contents of your notes seem to be a .env format, are you consuming that via a file/library?

@franklin What data from the items are you using? Do you need just field data or other data as well? Where and how are you consuming the data (via app, script, other)?

Yes, I use this to generate a .env file when a new user sets up the repo.
The .env file isn't in version control so it's easier to just generate it on the fly.
op read op://<vault name or ID>/<item name or ID>/notesPlain works for me.

I thought about using the file templates tool but it's more work to test and set that up.

@kevin_li In some cases we store a json String within a field and running

op item get <item> --fields <field>

with v2 now returns sth like

"{""auths"":""bar""}}"

I ran into this because I use op to populate .tfvars files for terraform. Here's my workaround:

op item get "${OP_ITEM}" --fields label=notesPlain --format json | jq -r '.value' > "${TF_FILENAME}"

jq returns quoted strings by default for some reason too, but you can use the -r (raw) option to disable that behavior.

@franklin is it feasible for you to run

op read op://path/to/item-field

?

I mentioned before that we are working on this issue. However, I have recently found out that this is the expected behaviour, and hence I was wrong in considering this a bug.

For example, assuming a field with value "world":

The value stored in the field is "world", if that is encoded to CSV as "world", the quotes are lost because the valid way to decode "world" is to world. So the "" are added ("" is the escaped variant of ") to signal that the " are to be decoded and should be in the output.

Looking forward to hearing from you all about this.

Best,
Horia