Yq: Allow to write raw values

[9you]

When using a large number as new value, in will be converted to a mathematical representation. It may cause unintended behavior. May be we can have some flag to specify that we want to write inputed value as raw String instead of convert it to number.

Use following command:

yaml w -i test.yml key "10000000"

Result:

key: 1e+07

[mikefarah]

Yep this is part of a larger problem atm, the same issue exists when trying to set other non-string values like null, or '.inf' and typings. It would be good to have some sort of 'raw' flag or something - then you could force a string by doing something like:

yaml new --raw key "!!str 100000" 

which would output:

key: !!str 100000

and nulls like:

yaml new --raw key "null" 

which would output:

key: null

[kchrusciel]

Hi guys, I get the same problem, this is a blocker point for me. Any plans to fix it?

[tomcurran]

Having the same issue as @9you

[dobesv]

It does seem to be inconsistent in terms of whether it converts the input into a string or not:

$ yq n test.double_quoted_number \"123\" | \
  yq w - test.double_quote_processing '"new\nline\ttab"' | \
  yq w - test.double_quoted_word \"abc\" | \
  yq w - test.single_quoted_number "'123'" | \
  yq w - test.number 123  | \
  yq w - test.json '{"hello":"world"}' | \
  yq w - test.specials '{{ab{1"23}[]cya' | \
  yq w - test.true true | \
  yq w - test.true_str \"true\" | \
  yq w - test.null_value null | \
  yq w - test.null_str \"null\" | \
  yq w - test.tilde_value "~" | \
  yq w - test.tilde_str \"~\"
test:
  double_quoted_number: "123"
  double_quote_processing: new\nline\ttab
  double_quoted_word: abc
  single_quoted_number: '''123'''
  number: 123
  json: '{"hello":"world"}'
  specials: '{{ab{1"23}[]cya'
  "true": true
  true_str: "true"
  null_value: "null"
  null_str: "null"
  tilde_value: "~"
  tilde_str: "~"

• If I provide a double-quoted string, it passes it through unchanged, complete with the double quotes
• If the string has other special characters (including single quotes), it wraps it in single quotes to keep it a string
• If the parameter is numeric, true, or false, it passes it through as a number or boolean

I suppose if this behavior is kept, it would be great to document clearly what the behavior is, e.g.

Value Parsing and Conversion

1. If the input is a valid YAML number or boolean (true/false, it will be written to the output as a number or boolean
2. If the input is wrapped in double quotes, the characters between the double quotes will always be written as a string, even if they look like a number or boolean. The output will be a double quoted string if required to ensure it is a valid string value. To ensure a value is always written as a string wrap it in double quotes (on the command line these may have to be prefixed with a backslash)
3. Otherwise the argument is taken to be a string, and will be wrapped in single quotes if necessary

[mikefarah]

Documenting the behaviour clearly sounds like a very good idea. Should have done before. I'll add it to my list.

Basically I've tried to make it so the most common tasks are easy to do (e.g. if you specify a number, then it's most likely a number). But yes - documentation.

[hassbert]

Hi there,
I experience a different behavior with the 3.0.0-beta version:

When I do an escape for the quotes \" then it converts always to single quotes with double quotes in the output '":

$ yq n test.double_quoted_number \"123\" | \
>   yq w - test.double_quote_processing '"new\nline\ttab"' | \
>   yq w - test.double_quoted_word \"abc\" | \
>   yq w - test.single_quoted_number "'123'" | \
>   yq w - test.number 123  | \
>   yq w - test.json '{"hello":"world"}' | \
>   yq w - test.specials '{{ab{1"23}[]cya' | \
>   yq w - test.true true | \
>   yq w - test.true_str \"true\" | \
>   yq w - test.null_value null | \
>   yq w - test.null_str \"null\" | \
>   yq w - test.tilde_value "~" | \
>   yq w - test.tilde_str \"~\"
test:
  double_quoted_number: '"123"'
  double_quote_processing: '"new\nline\ttab"'
  double_quoted_word: '"abc"'
  single_quoted_number: '''123'''
  number: 123
  json: '{"hello":"world"}'
  specials: '{{ab{1"23}[]cya'
  true: true
  true_str: '"true"'
  null_value: null
  null_str: '"null"'
  tilde_value: ~
  tilde_str: '"~"'

I am using Ubuntu as WSL:

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 18.04.3 LTS
Release:        18.04
Codename:       bionic

[dobesv]

I think rather than have "raw" input, it would be nice to have a way to specify that the value should be parsed as a YAML string.

For example yq n d -y '{"hello":"world"}' --> hello: world

This would obviously work for arrays, type annotations, and so on.

Also being able to have the value read from a file (parsed as YAML) would be great, like: yq n d -f test.yaml would be roughly the same as yq p test.yaml d and yq w x.yaml d test.yaml would be similar to yq p test.yaml d | yq m x.yaml, except it would leave stdin available as an option and do things in the other order.

[mikefarah]

That's an interesting feature...could be a neat extension. I think it's worth raising a separate card..

I've document the (current) V3 behavior here:

https://mikefarah.gitbook.io/yq/usage/value-parsing
and added it to the breaking changes doc here:
https://mikefarah.gitbook.io/yq/upgrading-from-v2#parsing-values-from-the-cli

[dobesv]

@mikefarah I think if you add support for --tag !!seq and --tag !!map then you'd cover all the bases very nicely, since if someone wants to pass in a whole object or array in YAML format they can use those tags to specify it.

[adaughterson]

I've got a similar one, and some kind of workaround would be great.

The string '20200127.5' gets converted to its scientific notation form of 2.02001275e+07. A flag to preserve 'stringiness' would be cool.

[dobesv]

@adaughterson in version 3 he is adding feature where if you specify --tag !!str it will always interpret the argument as a string and not as a number.

[mikefarah]

Fixed in https://github.com/mikefarah/yq/releases/tag/3.0.1