[yarcob]

If you would use that variable, you wouldn't set it globally. You would set it only for the syncthing process.

For example, when you use systemd to run syncthing, you can configure the environment for syncthing in the unit file.

Other Go programs on your machine won't be affected.

[rkagerer]

I wonder if my annoyance stems from a difference between Windows vs. Linux conventions?

I hark back to when environment variables were set globally on a machine (back in DOS days).

I realize NTVDM emulation introduced the ability to configure more granular ones (eg. system vs. user) and you can now create a shortcut[1] that launches an intermediate step which tailors the environment for a single process. But always viewed that as a cludgey convenience for users, not a design paradigm for developers. (Also with at least six[2] different places to check for where Windows envvars come from, I typically favor the expliciteness of command line switches).

What happens if someone's creating a script that will shell out simultaneously to multiple Go programs? Do they all inherit the parent's environment variables? Does the script now have to tailor the same-named variable for each one?

Am I doing something wrong or is this easier on Linux and us Windows schmucks got left behind?

Thanks for any elucidation...

[1] https://stackoverflow.com/questions/3036325/can-i-set-an-env...

[2] https://flylib.com/books/en/4.53.1.59/1/#:~:text=Environment...

[yarcob]

> What happens if someone's creating a script that will shell out simultaneously to multiple Go programs? Do they all inherit the parent's environment variables?

By default, every process inherits the environment of its parent process. So if you set an environment variable (eg. with the EXPORT command in bash), then every process you launch from the shell will have the same value for the environment variable.

However, you can set environment variables for each command that you execute.

So for example in a shell script you could do something like this:

    # set the environment variables value to 4
    # valid for all subsequently executed commands
    export GOMAXPROCS=4
    
    # run syncthing but limit it to 2 processors
    # defining the variable like this it will only affect this command
    GOMAXPROCS=2 /usr/local/bin/syncthing

    # run some other go program
    # the environment var will be set to the value 4 again
    /usr/local/bin/other-go-program

The beauty of using environment variables is that they are much more flexible than command line options.

For example, assume I execute a script from someone else, who did not set GOMAXPROCS. Then I could just set the GOMAXPROCS variable and then execute the script. I could change the config without needing to edit the script!