~/code
» cd foo
~/code/foo
» git init
± foo:main:/
» touch .env
± foo:main:/
» git add .
± foo:main:/
» g s
On branch main
No commits yet
Changes to be committed:
(use "git rm --cached <file>..." to unstage)
new file: .env
± foo:main:/
»
File is added, kaboom. "It should be in .gitignore" yes, true, but that has nothing to do with it not getting committed because it is hidden.
And even with it in .gitignore, I've dealt with multiple security incidents where someone has managed to commit it anyways. (And yes, I'm aware there are commands to do this, but what I haven't figured out is why someone would work around the safety and not think "what's the point of this?" prior to the bullet ending up in the foot.)
I hate that it's hidden too. There's no reason for it to be hidden and arguably some reason for it not to be hidden.
I did discover one reason for it not to be just "env" though, which surprised me, which is that "source env" will yield "bash: source: /usr/bin/env: cannot execute binary file". I did not expect the source command to use the $PATH to resolve the filename. Probably some minor security issues that can result from that out there in the world. Arguably anyone loading it should use "source ./.env" or equivalent, with full path.
It's documented in the bash manual, of course. But it is rather complicated as to when it will and will not use $PATH.
> If filename does not contain a slash, . searches for it. If -p is supplied, . treats path as a colon-separated list of directories in which to find filename; otherwise, . uses the directories in PATH to find filename. filename does not need to be executable. When Bash is not in POSIX mode, it searches the current directory if filename is not found in $PATH, but does not search the current directory if -p is supplied. If the sourcepath option (see The Shopt Builtin) is turned off, . does not search PATH.
From "The Open Group Base Specifications Issue 8 - IEEE Std 1003.1-2024" [2]:
. file
> If file does not contain a <slash>, the shell shall use the search path specified by PATH to find the directory containing file. Unlike normal command search, however, the file searched for by the dot utility need not be executable.
So it seems that it's not something Bash specific.
Comments
start with making it a dot file. Why would you want to hide the fact your app was using loaded environment variables?
The fact that it's hidden means it doesn't get commited by accident in most git repos unless explicitly added or configured that way.
No, it won't.
File is added, kaboom. "It should be in .gitignore" yes, true, but that has nothing to do with it not getting committed because it is hidden.And even with it in .gitignore, I've dealt with multiple security incidents where someone has managed to commit it anyways. (And yes, I'm aware there are commands to do this, but what I haven't figured out is why someone would work around the safety and not think "what's the point of this?" prior to the bullet ending up in the foot.)
there shouldn't be any secrets in it so committing it shouldn't be a huge problem.
Granted, but on the other hand: the entire history of this profession.
I hate that it's hidden too. There's no reason for it to be hidden and arguably some reason for it not to be hidden.
I did discover one reason for it not to be just "env" though, which surprised me, which is that "source env" will yield "bash: source: /usr/bin/env: cannot execute binary file". I did not expect the source command to use the $PATH to resolve the filename. Probably some minor security issues that can result from that out there in the world. Arguably anyone loading it should use "source ./.env" or equivalent, with full path.
It's documented in the bash manual, of course. But it is rather complicated as to when it will and will not use $PATH.
From the Bash manual [1]:
> If filename does not contain a slash, . searches for it. If -p is supplied, . treats path as a colon-separated list of directories in which to find filename; otherwise, . uses the directories in PATH to find filename. filename does not need to be executable. When Bash is not in POSIX mode, it searches the current directory if filename is not found in $PATH, but does not search the current directory if -p is supplied. If the sourcepath option (see The Shopt Builtin) is turned off, . does not search PATH.From "The Open Group Base Specifications Issue 8 - IEEE Std 1003.1-2024" [2]:
> If file does not contain a <slash>, the shell shall use the search path specified by PATH to find the directory containing file. Unlike normal command search, however, the file searched for by the dot utility need not be executable.So it seems that it's not something Bash specific.
[1]: https://www.gnu.org/software/bash/manual/html_node/Bourne-Sh... )
[2]: https://pubs.opengroup.org/onlinepubs/9799919799/utilities/V...