Or even simpler: why on earth are you using double quotes for a string if you don't want double-quote behaviour? Anything like this should just be in 'single quotes'... Any developer getting to "its parser changed a secret while reading it" and "By the time the bcrypt bug blocked SecretSpec," from basic shell semantics is frankly astonishing. I mean this on an organisational/team level, not as a personal attack on anyone, but the hubris is incredible to me.
This feels like the exact type of solution a badly prompted and poorly piloted AI tool manically follows to an absurd conclusion if you don't step in and tell it to do it the obvious and correct way instead of re-inventing the wheel.
(I would also argue most of the point of a .env file being what it is that you can source it in a shell?
Does the author here have any sane argument for not using a yaml/json/whatever file and XKCD-927ing it instead? Is this not just introducing a flaw when `source .env` stops behaving like expected?)
Comments
Or even simpler: why on earth are you using double quotes for a string if you don't want double-quote behaviour? Anything like this should just be in 'single quotes'... Any developer getting to "its parser changed a secret while reading it" and "By the time the bcrypt bug blocked SecretSpec," from basic shell semantics is frankly astonishing. I mean this on an organisational/team level, not as a personal attack on anyone, but the hubris is incredible to me.
This feels like the exact type of solution a badly prompted and poorly piloted AI tool manically follows to an absurd conclusion if you don't step in and tell it to do it the obvious and correct way instead of re-inventing the wheel.
(I would also argue most of the point of a .env file being what it is that you can source it in a shell? Does the author here have any sane argument for not using a yaml/json/whatever file and XKCD-927ing it instead? Is this not just introducing a flaw when `source .env` stops behaving like expected?)