3 ms·

Because that’s annoying. YAML is often written and read by humans. If you want a verbose and more regular way to do it, there is always JSON. But JSON is really

Because that’s annoying. YAML is often written and read by humans. If you want a verbose and more regular way to do it, there is always JSON. But JSON is really annoying to deal with for humans, although it is much better than YAML for several applications.

hnlmorg 2y ago
You don’t actually need quotes to define a string in YAML. Eg the following syntax User: Name: >- Bob Phone: >- 01234 56789 Description:>- This is a multi line description That’s both readable and parses your records as strings. Edit: This stack overflow like provides more details https://stackoverflow.com/questions/3790454/how-do-i-break-a-string-in-yaml-over-multiple-lines https://stackoverflow.com/questions/3790454/how-do-i-break-a...
- mdaniel 2y ago
  I can't tell if it's irony or not given the sentiment in this thread, but that is not a declaration of a multiline Description field, that's a field of User named "Description:>-" that happens to be missing its trailing ":" Seeing that used systemically, versus just for "risky" fields makes me want to draw attention to the fantastic remarshal tool[1], which offers a "--yaml-style >" (and "|" and the rest) which will render yaml fields quoted as one wishes 1: https://github.com/remarshal-project/remarshal#readme https://github.com/remarshal-project/remarshal#readme and/or $(brew install remarshal)
  - hnlmorg 2y ago
    > I can't tell if it's irony or not given the sentiment in this thread, but that is not a declaration of a multiline Description field, that's a field of User named "Description:>-" that happens to be missing its trailing ":" The trailing ‘:’ was there right after the ‘n’. Examples of this syntax: https://github.com/lmorg/murex/blob/master/builtins/core/arraytools/2darray_doc.yaml https://github.com/lmorg/murex/blob/master/builtins/core/arr... I do agree it’s a bit of a kludge. But if you want data types and unquoted strings then anything you do to the syntax to denote strings over other data types then becomes a bit of a kludge. The one good thing about this kludge is it allows for string literals (ie no complicated escaping rules). > Seeing that used systemically, versus just for "risky" fields makes me want to draw attention to the fantastic remarshal tool[1], which offers a "--yaml-style >" (and "|" and the rest) which will render yaml fields quoted as one wishes I don’t really understand what you’re alluding to here.
    - mdaniel 2y ago
      Tell us that you didn't try to use that example without telling us you just eyeballed the post $ /usr/local/opt/ansible/libexec/bin/python3 -c 'import sys, yaml; print(yaml.safe_load(sys.stdin.read()))' <<YML User: Name: >- Bob Phone: >- 01234 56789 Description:>- This is a multi line description YML yaml.scanner.ScannerError: while scanning a simple key in "<unicode string>", line 6, column 6: Description:>- $ gojq --yaml-input . <<YML User: Name: >- Bob Phone: >- 01234 56789 Description:>- This is a multi line description YML gojq: invalid yaml: <stdin>:6 6 | Description:>- ^ could not find expected ':' That's because, for better or worse, yaml considers that a legitimate key name, just missing its delimiter $ gojq --yaml-input . <<YML User: Name: >- Bob Phone: >- 01234 56789 Description:>-: This is a multi line description YML { "User": { "Description:>-": "This is a multi line description", "Name": "Bob", "Phone": "01234 56789" } } This exchange in a thread complaining about the whitespace sensitivity doesn't escape me As for remarshal, it was the systemic application of that quoting style that made me think of it, since writing { Name: >- Bob} is the worst of both worlds: not as legible as the plain unquoted version, not suitable for grep, and indentation sensitive
      - hnlmorg 2y ago
        The issue is the lack of white space between the : and the >, not a missing : at the end. I’m typing this on my phone so the odd syntax error might creep in but the key pointer is the examples I linked to and the block token I’ve described. Further to that point, none of the example links I’ve shared have the : at the end and I have production code that works using the formatting I’ve described. So you’re flat out wrong there with your assumption that block keys always terminate with : > As for remarshal, it was the systemic application of that quoting style that made me think of it, since writing { Name: >- Bob} is the worst of both worlds: not as legible as the plain unquoted version, not suitable for grep, and indentation sensitive You wouldn’t write code like that because >- denotes a block and you’re now inlining a string. I mean I’ve shared links explaining how this works and you’re clearly not reading them. At the end of the day, I’m not going to argue that >- (and its ilk) solves everything. It clearly doesn’t. If you want to write “minimized” YAML using JSON syntax then you’re far far better off quoting the string. But if you are writing a string in YAML and either don’t want to deal with quotation marks, or need that string to be a string literal (ie not having to escape things like quotation marks) then my suggestion is an option. It’s not there as a silver bullet but it is a lesser known feature of YAML. Hence me sharing. Now go read the links and understand it better. You might genuinely find it useful under some scenarios ;)

hnlmorg 2y ago

You don’t actually need quotes to define a string in YAML. Eg the following syntax User: Name: >- Bob Phone: >- 01234 56789 Description:>- This is a multi line description That’s both readable and parses your records as strings. Edit: This stack overflow like provides more details https://stackoverflow.com/questions/3790454/how-do-i-break-a-string-in-yaml-over-multiple-lines https://stackoverflow.com/questions/3790454/how-do-i-break-a...

mdaniel 2y ago
I can't tell if it's irony or not given the sentiment in this thread, but that is not a declaration of a multiline Description field, that's a field of User named "Description:>-" that happens to be missing its trailing ":" Seeing that used systemically, versus just for "risky" fields makes me want to draw attention to the fantastic remarshal tool[1], which offers a "--yaml-style >" (and "|" and the rest) which will render yaml fields quoted as one wishes 1: https://github.com/remarshal-project/remarshal#readme https://github.com/remarshal-project/remarshal#readme and/or $(brew install remarshal)
- hnlmorg 2y ago
  > I can't tell if it's irony or not given the sentiment in this thread, but that is not a declaration of a multiline Description field, that's a field of User named "Description:>-" that happens to be missing its trailing ":" The trailing ‘:’ was there right after the ‘n’. Examples of this syntax: https://github.com/lmorg/murex/blob/master/builtins/core/arraytools/2darray_doc.yaml https://github.com/lmorg/murex/blob/master/builtins/core/arr... I do agree it’s a bit of a kludge. But if you want data types and unquoted strings then anything you do to the syntax to denote strings over other data types then becomes a bit of a kludge. The one good thing about this kludge is it allows for string literals (ie no complicated escaping rules). > Seeing that used systemically, versus just for "risky" fields makes me want to draw attention to the fantastic remarshal tool[1], which offers a "--yaml-style >" (and "|" and the rest) which will render yaml fields quoted as one wishes I don’t really understand what you’re alluding to here.
  - mdaniel 2y ago
    Tell us that you didn't try to use that example without telling us you just eyeballed the post $ /usr/local/opt/ansible/libexec/bin/python3 -c 'import sys, yaml; print(yaml.safe_load(sys.stdin.read()))' <<YML User: Name: >- Bob Phone: >- 01234 56789 Description:>- This is a multi line description YML yaml.scanner.ScannerError: while scanning a simple key in "<unicode string>", line 6, column 6: Description:>- $ gojq --yaml-input . <<YML User: Name: >- Bob Phone: >- 01234 56789 Description:>- This is a multi line description YML gojq: invalid yaml: <stdin>:6 6 | Description:>- ^ could not find expected ':' That's because, for better or worse, yaml considers that a legitimate key name, just missing its delimiter $ gojq --yaml-input . <<YML User: Name: >- Bob Phone: >- 01234 56789 Description:>-: This is a multi line description YML { "User": { "Description:>-": "This is a multi line description", "Name": "Bob", "Phone": "01234 56789" } } This exchange in a thread complaining about the whitespace sensitivity doesn't escape me As for remarshal, it was the systemic application of that quoting style that made me think of it, since writing { Name: >- Bob} is the worst of both worlds: not as legible as the plain unquoted version, not suitable for grep, and indentation sensitive
    - hnlmorg 2y ago
      The issue is the lack of white space between the : and the >, not a missing : at the end. I’m typing this on my phone so the odd syntax error might creep in but the key pointer is the examples I linked to and the block token I’ve described. Further to that point, none of the example links I’ve shared have the : at the end and I have production code that works using the formatting I’ve described. So you’re flat out wrong there with your assumption that block keys always terminate with : > As for remarshal, it was the systemic application of that quoting style that made me think of it, since writing { Name: >- Bob} is the worst of both worlds: not as legible as the plain unquoted version, not suitable for grep, and indentation sensitive You wouldn’t write code like that because >- denotes a block and you’re now inlining a string. I mean I’ve shared links explaining how this works and you’re clearly not reading them. At the end of the day, I’m not going to argue that >- (and its ilk) solves everything. It clearly doesn’t. If you want to write “minimized” YAML using JSON syntax then you’re far far better off quoting the string. But if you are writing a string in YAML and either don’t want to deal with quotation marks, or need that string to be a string literal (ie not having to escape things like quotation marks) then my suggestion is an option. It’s not there as a silver bullet but it is a lesser known feature of YAML. Hence me sharing. Now go read the links and understand it better. You might genuinely find it useful under some scenarios ;)