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

YAML property names get mixed up if one contains asterisk * #1323

Open
qqilihq opened this issue Aug 31, 2022 · 3 comments
Open

YAML property names get mixed up if one contains asterisk * #1323

qqilihq opened this issue Aug 31, 2022 · 3 comments
Labels

Comments

@qqilihq
Copy link

qqilihq commented Aug 31, 2022

Describe the bug

YAML property names get replaced if one of them contains an asterisk * when running the “merge YAML” example.

Below, this is the case for image/*. Note that for this bug report, I’m “merging” just a single YAML to illustrate the issue.

Version of yq: 4.27.3
Operating system: mac
Installed via: homebrew

Input Yaml
data1.yml:

example:
  image/webp:
  image/svg+xml:
  image/jpeg:
  image/png:
  image/*:

Command
The command you ran:

yq ea '. as $item ireduce ({}; . * $item )' data1.yml

Actual behavior

example:
  image/*:
  image/*:
  image/*:
  image/*:

Expected behavior

example:
  image/webp:
  image/svg+xml:
  image/jpeg:
  image/png:
  image/*:

Additional context

@qqilihq qqilihq changed the title YAML property names get mixed up if one contains * YAML property names get mixed up if one contains asterisk * Aug 31, 2022
@mikefarah
Copy link
Owner

Ah yeah this is a hang-over (and backwards compatibility) for yq 3 - where '*' was used as a wildcard.

Hmm I think the best way to fix this without impacting existing users is to add a new flag that disables that functionality :/

@qqilihq
Copy link
Author

qqilihq commented Sep 9, 2022

Many thanks for the feedback. I worked around this for now by sed'ing the * to a placeholder, then running yq and then replacing it back. This works for now :-)

@bitdivine
Copy link

A flag such as --legacy that enables the old behaviour would also work. This way existing users would be impacted, but all they would have to do is to add --legacy to any affected scripts when they update. That way they don't have too much disruption but know that they need to sit down and update their scripts at some time. They will have had due warning that this thing is going to go away. Otherwise new users will have to tangle with old patterns that maybe you don't really want any more.

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

No branches or pull requests

3 participants