Why running go env in GoLand's terminal is different from system terminal - goland

The output in GoLand's terminal:
The output of go env in the OS terminal:

GoLand manages some of the environment variables and settings and overrides what's configured in the system so that it can create a reproducible environment between running code in the builtin terminal or when using the editor itself.
From what I can see in the images, I see that there are some differences around the GOFLAGS, GOPROXY, and GOMOD.
If I understand correctly what you are trying to do, then you need to enable the Go Modules support via Preferences | Go | Go Modules (vgo) and enable the Go Modules integration. Once you do this, you'll see that the GOFLAGS value will change.
There you can also set the Proxy field value to configure the GOPROXY environment variable.
The GOMOD difference comes from the directory where you invoked the go env command, as in this case they seem to be different directories. Invoke the command in the same directory in both IDE terminal and OS terminal and you'll see the same value. It indicates which, if any, go.mod file is used in the current command.
Finally, I recommend upgrading to GoLand 2019.3 as it will automatically enable Go Modules support when it detects that the project is created in a directory with a go.mod file present.

Related

Can I use zsh as the default non-interactive shell for WSL2 Ubuntu?

I am trying to use Run/Debug Configurations on WebStorm, however it doesn't seem to source .zshrc and produces errors about not finding commands and environment variables. (An example of this would be yarn tauri dev when using Tauri)
I have installed Ubuntu 20.04 in WSL and the project I opened in WebStorm resides under the $HOME directory. WebStorm is installed in Windows.
For the interactive shell, I have made zsh the default by chsh -s $(which zsh), but when using Run/Debug Configurations it uses the default non-interactive shell, which is dash as far as I know. And my environment variables and PATH are all set in .zshrc, which is not sourced by dash.
It seems in CLion, it is possible to execute commands in the login shell according to this YouTrack issue, but such an option is not available on WebStorm.
Is it possible to use zsh instead of dash as the default non-interactive shell? If not, it would help me a lot to know what is the best practice in such situations.
There are several questions and points you make:
First, from the question title (and the summary at the end):
Can I use zsh as the default non-interactive shell for WSL2 Ubuntu?
Well, maybe (using symlinks), but it would be a really bad idea. So many built-in scripts rely on /bin/sh pointing to Dash, or at least Bash. While Zsh might be compatible with 99.9% of them, eventually there's a strong likelihood that some difference in Zsh would cause a system-level script to fail (or at least produce results inconsistent with those from Dash).
It is possible in Ubuntu to change the default non-interactive ("system" shell) from Dash to Bash with sudo dpkg-reconfigure dash. If you select "No" in the resulting dialog, then the system will be updated to point /bin/sh to bash instead of dash.
But not to Zsh, no.
when using Run/Debug Configurations it uses the default non-interactive shell, which is dash as far as I know
I don't run WebStorm myself, so I'm not sure on this exactly. Maybe #lena's answer (or another) will cover it for you, but if it doesn't, I'm noticing this doc page. It might be worth trying to specify Zsh in those settings, but again, I can't be sure.
And my environment variables and PATH are all set in .zshrc, which is not sourced by dash.
Hmm. I'm guessing you would need these set in a .profile/.zprofile equivalent regardless. I would assume that WebStorm is executing the shell as a non-interactive one, which means that it wouldn't even parse ~/.bashrc if Bash was your default shell.
... it would help me a lot to know what is the best practice in such situations.
Best practice is probably to make sure that your ~/.profile has any environment changes needed. Yes, this violates DRY (don't repeat yourself), but it's probably the best route.
Thanks to the answer here and the discussion below, I was able to figure it out. (Thank you, #NotTheDr01ds and #lena.)
The main problem is that WebStorm is installed on Windows and therefore knows only the environment variables in Windows. There are two ways to solve the problem as follows.
Sharing WSL's environment variable to Windows through WSLENV
Add the line below to .zshrc so that it sets $WSLENV when zsh starts.
export WSLENV=VAR_I_WANT_TO_SHARE:$WSLENV
# Don't forget to insert the colon
# And for some reason, appending the variable after $WSLENV didn't work well
In Windows, run
wsl -e zsh -lic powershell.exe
This runs WSL using zsh (logged-in and interactive), then runs powershell which brings you back to Windows. Although this doesn't seem to achieve anything, by going through zsh in WSL, .zshrc was sourced and therefore $WSLENV set as well. You can check if it worked well by running the below command after you've run the above.
$env:VAR_I_WANT_TO_SHARE
Run WebStorm from the PowerShell that was just created.
& 'C:\Program Files (x86)\JetBrains\WebStorm 2022.1.3\bin\webstorm64.exe'
When you run or debug any of the Run/Debug Configurations, you will see that the environment variable is shared successfully.
Setting the PATH in Windows
For most environment variables, the previous method works well. However, PATH is an exception. The Windows PATH is shared to WSL by default. The opposite doesn't work, probably because the PATH in WSL should not interfere with Windows.I've tried adding the $PATH of WSL into $WSLENV but it didn't seem to work.
In the end, what I did was manually adding each needed $PATH of WSL into the Windows PATH.
For example, if there was export PATH=$PATH:home/(username)/.cargo/bin in .zshrc, you can then add \\wsl$\Ubuntu\home\(username)\.cargo\bin to the Windows $env:Path using the Environment Variable window.
I might have made some mistakes, so feel free to leave an edit or comments.
You can try using npm config set script-shell command to set the shell for your scripts. Like npm config set script-shell "/usr/bin/zsh".
When npm run <script name> spawns a child process, the SHELL being used depends on NPM environment. Cм https://docs.npmjs.com/cli/run-script:
The actual shell your script is run within is platform dependent. By
default, on Unix-like systems it is the /bin/sh command, on Windows it
is the cmd.exe. The actual shell referred to by /bin/sh also depends
on the system. As of npm#5.1.0 you can customize the shell with the
script-shell configuration
See also https://github.com/npm/npm-lifecycle/blob/10c0c08fc25fea3c18c7c030d4618a401963355a/index.js#L293-L304

wsl: sbt, ivy configuration

I have sbt installed on my windows machine, and I have set SBT_OPTS with:
-Dsbt.ivy.home=C:/var/.ivy2
-Dsbt.global.base=C:/var/.sbt/
-Dsbt.repository.config=C:/var/.sbt/repositories
I want to have similar setup in WSL, but am not able to find where in wsl are these configured.
Where do I need to look for it in WSL to set in SBT_OPTS?
I don't use SBT, so I could be way off base here, but it appears from this answer that SBT_OPTS is simply an environment variable. Typically you will simply configure that in Linux (and WSL) by either:
One-time:
export SBT_OPTS="-D/home/username/.ivy2 ..."
Or so that it loads automatically by placing the same line in your ~/.bash_profile
Of course, you'll need to set all the paths to their WSL/Linux locations.

How stop RStudio from creating empty "R" folder within "/home" directory at every startup

After having set the path for the default working directory as well as my first (and only) project within RStudio options I wonder why RStudio keeps creating an empty folder named "R" within my "/home" directory every time it is started.
Is there any file I could delete/edit (eventually create) to stop this annoying behaviour and if so, where is it located ?
System: Linux Mint v. 19.3
Software: RStudio v. 1.3.959 / R version 3.4.4
Thanks in advance for any hints.
Yes, you can prevent the creation of the R directory — R is configurable via a set of environment variables.
However, setting these correctly isn’t trivial. The first issue is that many R packages are sensitive to the R version they’re installed with. If you upgrade R and try to load the existing package, it may break. Therefore, the R package library path should be specific to the R version.
On clusters, an additional issue is that the same library path might be read by various cluster nodes that run on different architectures; this is rare, but it happens. In such cases, compiled R packages might need to be different depending on the architecture.
Consequently, in general the R library path needs to be specific both to the R version and the system architecture.
Next, even if you configure an alternative path R will silently ignore it if it doesn’t exist. So be sure to manually create the directory that you’ve configured.
Lastly, where to put this configuration? One option would be to put it into the user environment file, the path of which can be specified with the environment variable R_ENVIRON_USER — it defaults to $HOME/.Renviron. This isn’t ideal though, because it means the user can’t temporarily override this setting when calling R: variables in this file override the calling environment.
Instead, I recommend setting this in the user profile (e.g. $HOME/.profile). However, when you use a desktop launcher to launch your RStudio, this file won’t be read, so be sure to edit your *.desktop file accordingly.1
So in sum, add the following to your $HOME/.profile:
export R_LIBS_USER=${XDG_DATA_HOME:-$HOME/.local/share}/R/%p-library/%v
And make sure this directory exists: re-source ~/.profile (launching a new shell inside the current one is not enough), and execute
mkdir -p "$(Rscript -e 'cat(Sys.getenv("R_LIBS_USER"))')"
The above is using the XDG base dir specification, which is the de-facto standard on Linux systems.2 The path is using the placeholders %p and %v. R will fill these in with the system platform and the R version (in the form major.minor), respectively.
If you want to use a custom R configuration file (“user profile”) and/or R environment file, I suggest setting their location in the same way, by configuring R_PROFILE_USER and R_ENVIRON_USER (since their default location, once again, is in the user home directory):
export R_PROFILE_USER=${XDG_CONFIG_HOME:-$HOME/.config}/R/rprofile
export R_ENVIRON_USER=${XDG_CONFIG_HOME:-$HOME/.config}/R/renviron
1 I don’t have a Linux desktop system but I believe that editing the Env entry to the following should do it:
Exec=env R_LIBS_USER=${XDG_DATA_HOME:-$HOME/.local/share}/R/%p-library/%v /path/to/rstudio
2 Other systems require different handling. On macOS, the canonical setting for the library location would be $HOME/Library/Application Support/R/library/%v. However, setting environment variables on macOS for GUI applications is frustratingly complicated.
On Windows, the canonical location is %LOCALAPPDATA%/R/library/%v. To set this variable, use [Environment]::SetEnvironmentVariable in PowerShell or, when using cmd.exe, use setx.

How do I find the silent install parameters for SceneBuilder?

I want to create a Chocolatey package to install Scene Builder, so I'm looking for a way to install Scene Builder silently in command line.
I downloaded a installer (SceneBuilder-8.4.1.exe) and try to install like below.
> SceneBuilder-8.4.1.exe /silent
However, it launches a install dialog similarly in the case when I double click a installer.
Does Scene Builder installer has a capability to install silently?
You could try to find out what kind of installer is used and look up the silent installation flags or you can try experimentally. The Chocolatey documentation says something like this
https://chocolatey.org/docs/helpers-install-chocolatey-package#silentargs-string
If you pass a "help" parameter to the installer it indicates some silent switches and some documentation.
PS> ./SceneBuilder-9.0.1.exe /?
---------------------------
Setup
---------------------------
The Setup program accepts optional command line parameters.
/HELP, /?
Shows this information.
/SP-
Disables the This will install... Do you wish to continue? prompt at the beginning of Setup.
/SILENT, /VERYSILENT
Instructs Setup to be silent or very silent.
/SUPPRESSMSGBOXES
Instructs Setup to suppress message boxes.
/LOG
Causes Setup to create a log file in the user's TEMP directory.
/LOG="filename"
Same as /LOG, except it allows you to specify a fixed path/filename to use for the log file.
/NOCANCEL
Prevents the user from cancelling during the installation process.
/NORESTART
Prevents Setup from restarting the system following a successful installation, or after a Preparing to Install failure that requests a restart.
/RESTARTEXITCODE=exit code
Specifies a custom exit code that Setup is to return when the system needs to be restarted.
/CLOSEAPPLICATIONS
Instructs Setup to close applications using files that need to be updated.
/NOCLOSEAPPLICATIONS
Prevents Setup from closing applications using files that need to be updated.
/RESTARTAPPLICATIONS
Instructs Setup to restart applications.
/NORESTARTAPPLICATIONS
Prevents Setup from restarting applications.
/LOADINF="filename"
Instructs Setup to load the settings from the specified file after having checked the command line.
/SAVEINF="filename"
Instructs Setup to save installation settings to the specified file.
/LANG=language
Specifies the internal name of the language to use.
/DIR="x:\dirname"
Overrides the default directory name.
/GROUP="folder name"
Overrides the default folder name.
/NOICONS
Instructs Setup to initially check the Don't create a Start Menu folder check box.
/TYPE=type name
Overrides the default setup type.
/COMPONENTS="comma separated list of component names"
Overrides the default component settings.
/TASKS="comma separated list of task names"
Specifies a list of tasks that should be initially selected.
/MERGETASKS="comma separated list of task names"
Like the /TASKS parameter, except the specified tasks will be merged with the set of tasks that would have otherwise been selected by default.
/PASSWORD=password
Specifies the password to use.
For more detailed information, please visit http://www.jrsoftware.org/ishelp/index.php?topic=setupcmdline
---------------------------
OK
---------------------------
http://www.jrsoftware.org/ishelp/index.php?topic=setupcmdline
The Universal Silent Switch Finder says this is an Inno Setup installer and suggests some switches.

using MPI: What on earth is "execvp error on file" error?

I am using my own laptop locally with win 10 system and intel parallel studio .
After I compiled my mpi code with mpiifort and run it with mpiexec for the first time. It warns me to input account and password, like below
I am sure I put in the correct password. But it just didn't work. What does "execvp error" mean? I never encountered this problem before on my old win8 system. I just installed this new win10 system on my laptop, everything is new. Could somebody please help me instead of making close vote without any comment? At least, say something
execvp error on file is the error from doing execvp system call. It is variant of exec system call used to start programs. In your case the mpiexec program tries to start the mpi-learning-pack.exe file on the target hosts (according to settings, probably some environment settings). This error says that it can't start your program on target hosts, because either it is not executable file, or cannot be found (not copied to target hosts or have no full path).
mpiexec does not copy file to targets, you should copy it to every target hosts.
You can also check if it executable by manually starting it on target host: just login to target host and type mpi-learning-pack.exe without mpiexec;
program may not start if there are no any of required library on target.
Or your account has no enough privileges like https://software.intel.com/en-us/forums/intel-clusters-and-hpc-technology/topic/607844 https://software.intel.com/en-us/forums/intel-clusters-and-hpc-technology/topic/624054
Or you just should use relative (mpiexec [options] .\mpi-learning-pack.exe) or full path (mpiexec [options] e:\w\work\fortran\_test_and_learning\mpi-learning-pack.exe) of target executable like in https://software.intel.com/en-us/forums/intel-clusters-and-hpc-technology/topic/624054

Resources