Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Long hashtable values incorrectly wraps #12

Open
jeff1evesque opened this issue Jul 27, 2017 · 4 comments
Open

Long hashtable values incorrectly wraps #12

jeff1evesque opened this issue Jul 27, 2017 · 4 comments

Comments

@jeff1evesque
Copy link

jeff1evesque commented Jul 27, 2017

I have the following generic logic:

import-module psyaml

## local variables
$my_arr = @()
$my_hash = @{}
$blahs = @('one', 'two', 'three')
$something = @(@{Name = 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx'})

## generate output
foreach ($someValue in $something) {
    foreach ($blah in $blahs) {
        $my_hash += @{$blah = $someValue.Name}
    }
}
$my_arr += @{'zzzz' = $my_hash}

## convert to yaml
$my_arr | ConvertTo-YAML

I end up getting output that looks like:

---

  zzzz: 
    one: >
    xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
    xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

 
    three: >
    xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
    xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

 
    two: >
    xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
    xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
@jeff1evesque
Copy link
Author

jeff1evesque commented Jul 27, 2017

I found the reason why the output is split into multiple lines. Personally, I would say an application should not bake into their program, the linter, or concepts of the linter. This should be like a post-processing, coupled into unit tests, and things of that nature. In this specific case, it should be up to the users, how long they want their values to be. Then, the linter is really up to them, and not this program / module.

@terrabitz
Copy link

+1 to this. Wrapping should be both optional and configurable. And when wrapping is done, the indentation should be correct according to the YAML spec (e.g. https://yaml-multiline.info/)

@PercussiveElbow
Copy link

+1 too. I have to use other tools to fix the multiline indentation with this library.

@delve
Copy link

delve commented Dec 28, 2019

+1
My use case is manipulating kubeconfig YAML files that sometimes have very long BASE64 strings embedded in them. Merely reading and rewriting these files with PSYaml breaks them.
Snippet of the initial state with 375k byte BASE64 value on one line with no breaks:

apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: LS0...

Yes, 375 thousand bytes with no line break. It's a BASE64 CA cert bundle, and that's simply what those look like. Execute:

$tmp = ConvertFrom-Yaml (Get-Content '.\kube.yml' -Raw)
Set-Content -Path '.\kube_test.yml' -Value (ConvertTo-Yaml $tmp)

Renders the following (snippet) with the BASE64 value folded every 80 bytes.

  apiVersion: 'v1' 
  clusters: 
  - 
      cluster: 
        certificate-authority-data: >
          LS0...

This can't be read by kubectl because the spaces embedded in the deserialized string aren't valid BASE64 (see the multiline doc linked above for the interpretation of the '>' syntax). The correct behavior in my case would be to simply drop the string in unchanged. There is no YAML block style (according to the link above anyway) that fits my requirements because any deserialization from block scalar format will inject unwanted characters. I need an option to not mung my input strings at all.

As it stands my workaround will be to tell users that they can't embed certificate data and will have to use the file reference syntax. And I'll tell them to find/write me a YAML support library or come here instead of complaining to me ;)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants