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
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...