On 1/5/25 6:17 AM, Tobi Laskowski wrote:
This does not cover the specific behaviour I am concerned with. I would expect something like:"Additionally, if it is in the environment at start up, the variable is automatically exported and shell options enabled subsequently through other means will be included in the exported value."
This is already documented in a couple of different places: PARAMETERS: "When the shell starts, it reads its environment and creates a shell variable from each environment variable that has a valid name, as de- scribed below (see ENVIRONMENT)." ENVIRONMENT: "On invocation, the shell scans its own environment and creates a parameter for each name found, automatically marking it for export to child processes." The SHELLOPTS description includes additional information that is specific to that variable, but the general property still applies.
I do not find it surprising that the values in SHELLOPTS are applied, I find it surprising that the pre-existence of a SHELLOPTS environment variable results in any future shell options being "sticky".
Standard environment variable behavior.
It is not possible to have a naive SHELLOPTS=myopt configured outside the
> shell without all future options being exported implicitly. It is possible, by removing the export attribute from SHELLOPTS, but you do have to explicitly take that step.
If this is the correct way to achieve this, that is fair enough. If SHELLOPTS is not intended to be used in this way then I would expect the documentation to include enough information that would discourage a user from falling into this trap.
I think the documentation already includes enough information about this.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU c...@case.edu http://tiswww.cwru.edu/~chet/
OpenPGP_signature.asc
Description: OpenPGP digital signature
