Summary: | Incompatible default shell configuration | ||
---|---|---|---|
Product: | Base System | Reporter: | mirabilos <tg> |
Component: | conf | Assignee: | freebsd-bugs (Nobody) <bugs> |
Status: | New --- | ||
Severity: | Affects Some People | CC: | jilles, markj, michael.osipov, pat, trasz |
Priority: | --- | ||
Version: | Unspecified | ||
Hardware: | Any | ||
OS: | Any |
Description
mirabilos
2023-10-05 17:00:07 UTC
The reasoning for exporting ENV was to make sure interactive non-login shells have the user's settings such as aliases and shell options, while not extending the startup files from the POSIX standard. However, this indeed has the problem that the ENV file must be readable by all POSIX-style shells. Perhaps the cleanest solution is to read, in interactive shells, a file with some hard-coded name from the user's home directory if ENV is not set. In an interactive login shell, this file would be read after .profile (if .profile did not set ENV). The standard dot.profile can then be changed to stop setting ENV. The hard-coded name could be something like .shrc or something new like .freebsdshrc. By the way, bash's decision to use the ENV file only when it is invoked as sh or in POSIX mode (in either case, only in interactive shells, as specified by POSIX) helps it here. > Perhaps the cleanest solution is to read, in interactive shells, a file with
> some hard-coded name from the user's home directory if ENV is not set. In an
That’s what mksh does: it expands "${ENV:-~/.mkshrc}".
I didn’t want to presume requesting for adding it to your sh, but if you’re in favour of that, it’d also solve the situation.
Otherwise, adding suitable lines sending other shells to their respective *rc files in the default $ENV are needed, yes.
Thanks!
|