examples: lang: Fix env0 example #765
Conversation
examples/lang/env0.mcl
Outdated
|
|
||
| print "print2" { | ||
| msg => fmt.printf("environment variable DOESNOTEXIT does not exist, defaulting to: %s", $y), | ||
| } | ||
|
|
||
| $z = sys.getenv("EMPTY", "456") | ||
| $z = sys.defaultenv("EMPTY", "456") | ||
|
|
||
| print "print3" { | ||
| msg => fmt.printf("same goes for epmty variables like EMPTY: %s", $z), |
Change function calls to the correct one, remove extra argument in getenv call, and fix typo.
|
I updated the commit message again, and I am using this option |
Indeed it is the proper way. For most patches (especially small ones) we don't need to preserve the history of our work on this change-- IOW, suppose we made some mistakes along the way of developing this patch, we don't need to record those in git master forever. So --force pushing over a feature branch is actually the ideal scenario. If this was a very large patch, particularly with multiple commits, it might be preferable to add new commits until the entire PR was fixed. This can in some rare instances help the submitter and reviewer keep track of what changes they've made and so on. Only at the end does the patchset typically get squashed into one or more commits. HTH Patch looks perfect now, will merge shortly. PS: Bonus points to look cool (just a lesson for future you) Sending small typo fix style patches is definitely useful, but you get more hacker style points when the same patchset also adds a test to permanently check for that kind of bug as well. It's not always possible, but when it is, it's cooler. |
|
Merged, thank you! |
Change the function call from
getenvtodefaultenv.