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

Plain output is converted/casted to other formats #294

Closed
electriquo opened this issue Feb 4, 2023 · 4 comments
Closed

Plain output is converted/casted to other formats #294

electriquo opened this issue Feb 4, 2023 · 4 comments
Labels
bug Something isn't working

Comments

@electriquo
Copy link

electriquo commented Feb 4, 2023

Describe the bug
When using a plain output, dasel converts the values and does not display them as plain, which also affects the selection of values.

For instance, integer values are being converted to exponent notation.

To Reproduce

$ echo '[4090849286]' | dasel -r json -w - '.all()'
4.090849286e+09

$ echo '[4090849286]' | dasel -r json '.all()'
4090849286

$ echo '{"foo": "bar"}' | dasel -r json ".filter(equal(foo,bar))"
{
  "foo": "bar"
}

$ echo '{"foo": 12345678}' | dasel -r json ".filter(equal(foo,12345678))"

$ echo '{"foo": 12345678}' | dasel -r json ".filter(equal(foo,1.2345678e+07))"
{
  "foo": 12345678
}

Expected behavior

dasel should not convert the values to any type and keep them as is so plain output and selection/filtration will work as expected.

Desktop (please complete the following information):

  • OS: Linux/MacOS
  • Version: 2.1.1

Relates to #245, #293

@electriquo electriquo added the bug Something isn't working label Feb 4, 2023
@electriquo
Copy link
Author

cc @TomWright

@TomWright
Copy link
Owner

This issue is caused by the fact that all comparisons are string comparisons.

The best way to solve this is to allow functions to accept arguments of different types.

The given example causes a comparison on the following types, which is obviously false since they are strings.

12345678.000000 string, 12345678 string

@TomWright
Copy link
Owner

This has been fixed here: 7e2937e

It's not merged to master or released yet but will be included in the larger set of encoding/decoding changes

@TomWright
Copy link
Owner

FYI This has been merged to master and is available in the development version. This will be included in the next relase.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants