I wanted to reinstall flutter but I am getting this error, how can I resolve it?
Run the following command to see if there are any dependencies you need to install to complete the setup (for verbose output, add the -v flag):
flutter doctor
You can update your PATH variable for the current session at the command line, as shown in Get the Flutter SDK. You’ll probably want to update this variable permanently, so you can run flutter commands in any terminal session.
The steps for modifying this variable permanently for all terminal sessions are machine-specific. Typically you add a line to a file that is executed whenever you open a new window. For example:
Determine the directory where you placed the Flutter SDK. You need this in Step 3.
Open (or create) the rc file for your shell. Typing echo $SHELL in your Terminal tells you which shell you’re using. If you’re using Bash, edit $HOME/.bash_profile or $HOME/.bashrc. If you’re using Z shell, edit $HOME/.zshrc. If you’re using a different shell, the file path and filename will be different on your machine.
export PATH="$PATH:[PATH_TO_FLUTTER_GIT_DIRECTORY]/flutter/bin"
Related
I'm learning to use Git. After installation I can open a Bash terminal on VS Code (I'm using Windows if that's relevant). Right after opening a Bash terminal, this command shows up automatically (the id and path are masked for privacy):
myid#machineid MINGW64 /c/Users/...
$ source C:/ProgramData/Anaconda3/Scripts/activate base
(base)
I guess it means it's using Anaconda to run the Git command. However, it appears many CMD commands that otherwise work normally in a Windows terminal don't work. For example, I can't create a new folder. This error comes up:
$ mkdir test
bash: /c/ProgramData/Anaconda3/Library/usr/bin/mkdir: Permission denied
(base)
Similarly, commands like ls or touch just don't work. But I find pwd works. I look at /c/ProgramData/Anaconda3/Library/usr/bin and see there are a bunch of CMD command exe files in there, such as mkdir.exe, rm.exe. I also look at the Git installation directory and find a folder with similar exe commands (C:\Program Files\Git\usr\bin)
On the other hand, I can still use Git commands. So this works (after manually creating the folder test):
$ git init
Initialized empty Git repository in C:/Users/.../test/.git/
(base)
Also, if I don't use VS Code, but use a Git CMD then everything works just fine.
So the question is how I can fix it? More specifically, how can I direct Git to use Git command base in VS Code instead of depending on Anaconda base? What it currently means to me is that if I uninstall Anaconda then Git may not work in VS Code at all.
I installed miniconda on our CentOS cluster and it all went fine. Then I asked miniconda to create a python 3.8 environment, and it went fine. However, when I try to activate the environment, I get the following error:
CommandNotFoundError: Your shell has not been properly configured to use 'conda activate'.
To initialize your shell, run
$ conda init <SHELL_NAME>
I verified, and it's a bash environment. So I ran conda init bash and I got the following outputs:
no change /MyPath/miniconda3/condabin/conda
no change /MyPath/miniconda3/bin/conda
no change /MyPath/miniconda3/bin/conda-env
no change /MyPath/miniconda3/bin/activate
no change /MyPath/miniconda3/bin/deactivate
no change /MyPath/miniconda3/etc/profile.d/conda.sh
no change /MyPath/miniconda3/etc/fish/conf.d/conda.fish
no change /MyPath/miniconda3/shell/condabin/Conda.psm1
no change /MyPath/miniconda3/shell/condabin/conda-hook.ps1
no change /MyPath/miniconda3/lib/python3.9/site-packages/xontrib/conda.xsh
no change /MyPath/miniconda3/etc/profile.d/conda.csh
no change /home/users/me/.bashrc
No action taken.
So nothing happens. And when I try to activate the new environment, then I still get the first error.
Any idea how I can fix this?
[Solution] Thanks to the answer below, the issue was that despite testing that I was running/using a bash, I still have to run "bash" in the command line before activating model.
have you tried manually adding to ~/.bashrc?
add export PATH="/home/username/miniconda/bin:$PATH" in your bashrc file. make sure to replace /home/username/miniconda with your actual path now save the file, quit and reopen the terminal should work I guess.
I'm trying to setup GoLand to use WSL 2 as in this guide: https://www.jetbrains.com/help/go/how-to-use-wsl-development-environment-in-product.html
I've installed Go in the Ubuntu distro following the linux instructions on the GoLang website, and go version prints outs the version I downloaded, so it appears that Go is working inside WSL.
So now I tried to create a new project in GoLand, and I'm getting errors, which appear to come from the fact that the SDK isn't loaded in GoLand. The guide doesn't offer much guidance on this, so I just tried to add a local SDK.
When I select /usr/local/go I get an error that it's not a valid SDK.
So I created the ~/go directory, and then updated my .zshrc file to export the GOPATH and GOROOT environment variables, even though they already showed up when I ran go env, doing this got them to show up on a simple env call.
But I'm still getting the invalid SDK error like above.
Is there a configuration step I'm missing that isn't spelled out in the guide? I came across this old post about creating symlinks to fake the expected directory structure. I haven't done this because it's a really old post, has comments that say this has been fixed, and seems like a really odd solution.
Support for Go SDK in WSL2 will be available in the next 2021.3 release, please see GO-10618.
October 2021 update.
2021.3 reaches Early Access Program at the moment. GoLand suggests selecting Go SDK on WSL2 mount if the location of the project is on WSL2 as well.
I experienced this on my Debian machine and I wasn't using WSL2. I found that the actual cause of the issue is that Goland is unable to read the directory /usr/local/go/bin due to inadequate permission.
A possible solution is to run the goland.sh script as root. The script can be found in the bin/goland.sh directory of the Goland IDE folder. Here is a simple command to do run Goland as the root
export HISTIGNORE='*sudo -S*' && echo "sudo-password-here" | sudo -S /absolute-path-to-goland.sh
export HISTIGNORE='*sudo -S*' tells bash history to ignore caching any command matching sudo -S* to bash history. This way, your sudo-password isn't saved into the bash-history file.
echo "sudo-password-here" | pipes your sudo password as input to the next command.
sudo -S tells bash to read input for password prompt from stdin, which has been provided through the echo command.
Alternatively, you can just install the latest version of Goland. Hopefully, it doesn't come with this bug
I'm not sure how to open Gnuplot from MobaXterm. I've been trying many different commands but they all don't work. When I try, I get the same error.
-bash: gnuplot: command not found
I'm curious if I downloaded Gnuplot to the wrong part of the computer or if I'm not getting the command right? I'm trying to write a program in shell script that opens Gnuplot on it's own and plots data through the shell script.
Any help is appreciated!
mobaxterm is not a linux server. So you cant install packages into it normally.
you must download plugins if you can find the plugin you are looking for
check their list here
http://mobaxterm.mobatek.net/plugins.html
and it seems gnuplot is not there .
in this case your easiest solution is to download cygwin and add gnuplot on it which is possible
other option is to run small virtual machine so you can test on it
in all cases mobaxterm is not real linux enviroment so to be sure your shel do work on normal linux machines you will need to develop and test on real linux
You can install the winbuild of gnuplot and add the path to the bin directory, with gnuplot.exe in it, to mobaxterm's PATH (probably set it in .initrc or .bashrc, whichever you prefer).
MobaXterm is a standalone program which 'emulates' a Linux terminal but has no idea about your frame system (e.g. your Windows and your programs). So if you type 'gnuplot' Moba has no idea what is this. You have to
change the current directory to where is wgnuplot.exe e.g.:
cd /drives/c/Program\ Files/gnuplot-4/bin
./wgnuplot.exe
or run directly it:
/drives/c/Program\ Files/gnuplot-4/bin/wgnuplot.exe
or change your $PATH:
PATH=$PATH:/drives/c/Program\ Files/gnuplot-4/bin
wgnuplot.exe
or create a script named 'gnuplot' which runs wgnuplot.exe
#File name: 'gnuplot'
#!/bin/sh
/drives/c/Program\ Files/gnuplot-4/bin/wgnuplot.exe
and place it into some $PATH directory:
`/bin` or `/usr/bin` or `/drives/c/WINDOWS` or `/drives/c/WINDOWS/system32`
or... :)
The simplest way I found out is to use the Moba Package Manager to install the win version of gnuplot.
Open MobaXterm and type MobApt. An GUI will open up and you can type in "gnuplot" in the filter field.
Just select and install the package, MobApt will take care of any dependencies for you.
I had run the MacPorts installer (2.0.3) for my OS X Leopard (10.5.8) which finished "successfully". Unfortunately the port command was not available so I looked in the MacPorts Guide which says that the installer should have run a so-called "postflight" script that sets the necessary environment variables. I tried to run the postflight script manually (which I downloaded from here), but the execution fails with the following output:
Detected the bash shell.
Your shell already has the right PATH environment variable for use with
MacPorts!
Your shell already has the right MANPATH environment variable for use with
MacPorts!
Your shell already has the right DISPLAY environment variable for use with
MacPorts!
Adding [default] tag to sources.conf if needed...
couldn't read file "/Contents/Resources/upgrade_sources_conf_default.tcl": no
such file or directory
Updating port image format...
couldn't read file "/Contents/Resources/images_to_archives.tcl": no such file or
directory
Synchronizing the MacPorts installation with the project's rsync server...
-bash: __PREFIX__/bin/port: No such file or directory
An attempt to synchronize your recent MacPorts installation with the project's
rsync server failed!
Please run 'sudo port -d selfupdate' manually to find out the cause of the
error.
You have succesfully installed the MacPorts system, launch a terminal and try it
out!
Read the port(1) manual page and http://guide.macports.org for help,
http://www.macports.org/contact.php if you need to get in touch with The
MacPorts Project.
Any ideas?
First invoke the port command directly:
$ /opt/local/bin/port help
If that comes back with something reasonable (like the help text) then it's just that your $PATH isn't being used by your current shell. Try logging off and back on again to resolve that in the short term (this will test that your .bashrc file is correctly configured) or you could just modify the PATH environment variable directly (which doesn't test .bashrc):
$ export PATH=$PATH:/opt/local/bin
You downloaded the postflight script but it alone cannot access the accessory scripts in Contents/ because those are located into the install package.
Those missing Tcl scripts are for upgrading from an older install, the log says PATH was already correctly configured but the macports bin directory could have the wrong position in PATH variables, for instance being at the end of PATH.
If you are doing a fresh install you can just only need PATH and MANPATH -you want man pages provided by macports before system's ones- as per [1]
[1] http://guide.macports.org/#installing.shell.postflight