login(1) traditionally sets a limited set of environment variables at, well, login time. Like su login will typically ask for a password even if one logins as oneself so that here is probably not ideal. Unix systems may have additional or different complications, e.g. if there is PAM pam_env(8) could add or remove environment variables from what was set by login. A copy of what login(1) does could thus create a different environment variable set than an actual login through PAM sets.
Then there are terminals and shells; terminals may or may not launch the subsequent process as a "login" shell. Shells may read different files when flagged as login and may end up with different env variables for login vs. non-login instances. There is existing literature on this topic.
So based on the unix, the login process, local system configuration, what shell the user uses, and local configuration for that shell there may be different environment variables set "by default."
You may be able to get a suitable list of environment variables with a login shell instance:
% export CANARY=tweet
% env -i bash -l -c 'env | grep CANARY'
/Users/jhqdoe/.profile: line 6: set: markdirs: invalid option name
%
this does clear environment variables from the parent process (env | grep CANARY would be where your $COMMAND goes). .profile here is actually for mksh, not bash. However, the above may not set necessary variables that the login workflow sets as it does not go through that code. These might be inspected to see what they are with a new login and then to run:
$ env > def
$ env -i bash -l -c 'env > new'
And then to compare the def and new files to see how they differ (possibly involving the sort and diff commands), then possibly updating the env command to set things that are missed before then doing the login shell.
Another idea is to snapshot the environment and use that as the default.
sudo... – Alex Vong Sep 07 '18 at 16:06~/.bashrcor~/.profile. – Alex Vong Sep 07 '18 at 16:09