oh good call, i’ll try and swap that in. i still do extremely bad “parsing” for update operations to preserve comments but for reading that seems like a better option.
Thing with all these ad-hoc dotenv implementations (and they pretty much all seem to be ad-hoc) is, that they are all incompatible (even the ones that claim to be compatible to certain others) and have a lot of unexpected behaviors in edge cases. dotenvy seems to be the most strict one out of those that I've looked at. That's good, but of course not very compatible. I think it requires quotes if you want to have any spaces (even between words) in the value. But it supports multi-line strings and properly parses escaped quotes.
I wrote down what I found out about several dotenv implementations here: https://github.com/panzi/punktum
Note that it's not fully up to date anymore, because I reported several bugs to certain implementations and some of them were fixed. Sometimes in an overly specific way. Didn't come around writing a new bug report in that case. Oh well.
Looking at the source of your implementation it looks like it doesn't support comments at the end of the line of a variable assignment. Also str.trim_matches('"') trims all the quotes (" and ') in e.g. FOO=""'BAR'"", meaning you can't have a string that starts/ends in '. You can for " if you wrap it in ' because of the order in wich you call trim_matches('"') for each. Also it of course ignores unbalanced quotes. The value in FOO="BAR" # comment will be read as BAR" # comment.
In general I think one should exactly specify in the documentation what syntax is supported, but not even dotenvy does that.
i just want to say thanks for this comment, inspired me to add my own bad parser to the mix and it has been really fun to work on. will add some more test cases and behavior changes based on your punktum repo, cool to have access to some thorough consideration on this format i have not thought too much about!
ah yeah, i thought of this more as a piece of art or something funny. i've updated the README to make this a bit more clear that it shouldn't be taken seriously.
bash is definitely fun! maybe an alias alone would be a flex but i like the idea. this bash cli for linear is one of my most used scripts. cargo was just kind of convenient here because it does so much for you: scaffolds out everything, puts an executable on your path, formatting, linting, testing, publishing.
bloody-albatross@reddit
Why not dotenvy? That one has an actually well thought out parser.
schpet@reddit (OP)
oh good call, i’ll try and swap that in. i still do extremely bad “parsing” for update operations to preserve comments but for reading that seems like a better option.
bloody-albatross@reddit
Thing with all these ad-hoc dotenv implementations (and they pretty much all seem to be ad-hoc) is, that they are all incompatible (even the ones that claim to be compatible to certain others) and have a lot of unexpected behaviors in edge cases. dotenvy seems to be the most strict one out of those that I've looked at. That's good, but of course not very compatible. I think it requires quotes if you want to have any spaces (even between words) in the value. But it supports multi-line strings and properly parses escaped quotes.
I wrote down what I found out about several dotenv implementations here: https://github.com/panzi/punktum Note that it's not fully up to date anymore, because I reported several bugs to certain implementations and some of them were fixed. Sometimes in an overly specific way. Didn't come around writing a new bug report in that case. Oh well.
Looking at the source of your implementation it looks like it doesn't support comments at the end of the line of a variable assignment. Also
str.trim_matches('"')trims all the quotes ("and') in e.g.FOO=""'BAR'"", meaning you can't have a string that starts/ends in'. You can for"if you wrap it in'because of the order in wich you calltrim_matches('"')for each. Also it of course ignores unbalanced quotes. The value inFOO="BAR" # commentwill be read asBAR" # comment.In general I think one should exactly specify in the documentation what syntax is supported, but not even dotenvy does that.
schpet@reddit (OP)
i just want to say thanks for this comment, inspired me to add my own bad parser to the mix and it has been really fun to work on. will add some more test cases and behavior changes based on your punktum repo, cool to have access to some thorough consideration on this format i have not thought too much about!
mamigove@reddit
thanks, but I will continue with direnv which is a much more robust and flexible solution.
biinjo@reddit
Why?
schpet@reddit (OP)
explained here: https://schpet.com/linklog/envset-updates-env-files
but i think mostly because i had a small amount of time to spend and i thought this was a fun way to spend it
biinjo@reddit
Ah okay. Good for you. I personally don’t recognize the problem.
schpet@reddit (OP)
ah yeah, i thought of this more as a piece of art or something funny. i've updated the README to make this a bit more clear that it shouldn't be taken seriously.
biinjo@reddit
Dont downplay your project because of a stranger’s (me) opinion.
schpet@reddit (OP)
i'm not :4)
Loaatao@reddit
Good! That’s what programming is all about. You have a problem, you find your own solution, and you share it. Good job OP
RoboticElfJedi@reddit
I also roll my own little utilities like this - I don't mind this at all. It could probably be done with a bash alias but that's no fun, is it?
schpet@reddit (OP)
bash is definitely fun! maybe an alias alone would be a flex but i like the idea. this bash cli for linear is one of my most used scripts. cargo was just kind of convenient here because it does so much for you: scaffolds out everything, puts an executable on your path, formatting, linting, testing, publishing.