I recently ran "conda init powershell" on my powershell in order to be able to activate conda environments (previously, "activate env_name" would not work).
However, I do not like what this has done to my powershell. For one, it always displays the current virual environment even if it is simply the base environment. Also, it no longer displays the current directory I am in.
I tried running commands like conda deinit, but it does not exist.
I tried removing anaconda from the path and restart the computer, but it did not work and powershell still recognized conda as a cmdlet.
I tried changing defaults from powershell, but it only lets me change Options, Font, Layout, and Colors. None of which are helpful.
Minimal reproducible example. With "pathtoanaconda/Scripts" in path, open PS and run "conda init powershell", restart powershell.
Notice in my screenshot how my current directory is not displayed.. Instead, I get a "(base) PS" for any directory I am in1
Oh.. I quickly realized https://superuser.com/questions/446827/configure-the-windows-powershell-to-display-only-the-current-folder-name-in-the has instructions that solve my problem.
I had to delete the information on that file in order to undo the conda init.
Related
I'm currently using a vscode over a remote ssh connection and cannot figure out how to set the search PATH for the vscode process itself. I have set the PATH for processes run in the terminal in my .bashrc file, which is also sourced from .bash_profile.
In spite of this, vscode complains that pipenv is not on the path although it is visible to my integrated terminal session. In my .bashrc I am loading environment modules to load versions of needed libraries, which get put on the PATH. Since I created my virtualenv using pipenv in the terminal, it knows which python version to use and makes a link to it in the environment definition. Because of the way python virtual environments work, the actual python binary is copied to the virtual environment. And because vscode has hardcoded paths where to look for virtual environments it is able to find the correct version of python that is in use (despite it not seeing it in the PATH).
In addition, hardcoding the path to pipenv using the extension setting python.pipenvPath still produces a "not found" error.
Solutions that I have seen elsewhere suggest launching vscode from the command line so that the process inherits the PATH settings. However, this will not work over a remote connection.
Flutter path is correct but still unable to be recognized by the windows command prompt. Looked everywhere asked anyone who used flutter still unable to figure out the problem.
Tried suggestions made on other questions similar to this still no luck and followed the tutorials on installing flutter did not work.
For Windows users (Windows 10)
Open Start menu and type env
Click on Environment Variables..
under User variables, select Path then click Edit
Click New then past this line C:\src\flutter\bin(supposing this is where 'bin' directory of Flutter is located on your machine)
Click 'OK'.
Restart is required to apply changes.
The command prompt you're using appears to be using elevated permissions and therefore will have the "system" environment variables but not your user ones necessarily. Try with a non-elevated command prompt... which you should be using anyways. Only use an elevated command prompt when absolutely needed as otherwise you could delete important things by accident. Also, you can run echo %PATH% to see what is actually in the path in the command prompt you're using.
If you want to use flutter across multiple users or need to use an elevated command prompt for some reason, add the path to flutter/bin to the system environment variables instead.
Adding the following things in the path solved the issue for me
C:\Program Files\Git\bin
C:\Program Files\Git\cmd
C:\Windows\System32
C:\Windows\SysWOW64\WindowsPowerShell\v1.0
C:\src\flutter\bin
For windows user make sure to include C:\Windows\System32 in your user PATH variable,this prevents the flutter command prompt from flashing when you click it.
I’m using the Powershell extension for Visual Studio Code. I updated the profile:
C:\Users\xxxxxxxx\Documents\WindowsPowerShell\Microsoft.VSCode_profile.ps1
To include some functions and variables that I want to make available to other scripts. When I reference a variable from the profile within another script, it does not appear that the profile has been loaded. I suspect this because the variable value is blank when I query it from the VS Code console. If I run the same test from the standard Powershell console with an associated profile, the variable value is resolved.
Can anyone tell me what, if anything, I need to do to use a Powershell profile in VS Code while debugging?
There are several profiles. The starting point is the four locations that you can find by reading the following properties of PowerShell's built-in $profile variable.
$profile.CurrentUserAllHosts
$profile.CurrentUserCurrentHost
$profile.AllUsersCurrentHost
$profile.AllUsersAllHosts
As noted in this article by The Scripting Guy, because Windows has both Powershell and the Powershell ISE, you have at least two possible values of Current Host, so at least 6 profiles.
I've tested this in the Visual Studio Code terminal window, and it seems that the "CurrentHost" profiles are the same as you get by simply running a powershell instance. I'd assume then that Code isn't seen as a distinct host, and just runs a normal powershell.
Once you've got that far, there's another possible complication, which is that the AllUsers profiles are down in C:\Windows\System32 and hence on a 64 bit system, also mirrored in C:\Windows\SysWOW64\. So depending on whether you are using a 32 or 64 bit editor, and whether the Powershell is hosted in a 32 or 64 bit process, it is quite possible that the file you are editing has no influence on the Powershell.
Inside your debug session run: $profile. This will return the path to currently used profile file, so you can make your changes there.
Alternatively you could change the system wide profile in C:\Windows\System32\WindowsPowerShell\v1.0\profile.ps1
With the just released version 0.10.0 of the VS Code PowerShell extension debugging with a previously loaded profile.ps1 being available is now implemented. Note that the interactive console and the debugger share the same PS session.
If you type $profile in the "PowerShell Integrated Console" of VSCode, you will see the path to the profile used:
C:\Users\xxx\Documents\WindowsPowerShell\Microsoft.VSCode_profile.ps1
Now if you type $profile in a normal terminal, you will see your "normal" profile: C:\Users\xxx\Documents\WindowsPowerShell\Microsoft.PowerShell_profile.ps1
Now the easiest solution that did the trick for me is to create a hard link between the two files (the VSCode_profile.ps1 file didn't exist in my case):
mklink /H Microsoft.VSCode_profile.ps1 Microsoft.PowerShell_profile.ps1
Reload VSCode and you are all set!
I am trying to change the default Jupyter Notebook start directory on my Windows 7 Enterprise machine. Other answers have suggested changing the "Start In" field found through Right-click>Properties>Shortcut on the Jupyter program in my Start menu, however this doesn't have any effect. When I change this field to my desired directory and try running the program it still opens in the default directory, when I recheck the "Start In" field it is the same as whatever I had changed it to so it looks like it isn't being changed back by Windows, rather it's being disregarded entirely. For reference the default directory is at P:\ which is not a local directory and is hosted on my company servers, and I am trying to change the Jupyter startup directory to C:.
I'm sure the path is correct - I've tried a few different ones and they are working with autocomplete. I should mention this is a locked down corporate machine and I have to run Jupyter as administrator or else it exits immediately. I do have elevated rights and have checked the user permissions on Jupyter. This is using the Jupyter that comes as default with the current Python 3.5 distribution of Anaconda - I have also tried reinstalling the whole Anaconda package and I'm currently working with a fresh default install.
I am wondering if there is perhaps a way through changing the startup script that is run when you execute the program?
Found the solution - go to your Anaconda install directory (for me this was C:\Anaconda3) and open the file cwp.py in a text editor. Change the line
os.chdir(documents_folder)
to
os.chdir("C:\\my\\path\\here").
I'm having a very weird issue with the command line and running Ant. I point the path variable at the location of my Ant bin directory (C:\Ant\bin) and when i go into a command window and type PATH it shows the location in it. But when I go to run Ant by typing "ant" it does nothing and states that it isn't recognized. But when I go to the run window (Windows+R) and type "ant" it runs it.
I have restarted Windows twice and the problem still persists. I am running Windows Vista Ultimate with SP1 installed. I have tried "Running as Administrator" with no difference.
Any one experience anything like this before?
Sometimes you can set a system-wide (or even just personal) Environment Variable and it'll cure it, as opposed to just setting it in your shell.
Go to the Control-panel, then System, then Advanced, and look for the button on Environment Variables. From there, you can follow your nose.
Good luck.
Ant also depends on Java to be on the path. Do you have that?
I would also check to make sure the environment variables ANT_HOME and JAVA_HOME are set up properly in the console.
Is there any chance that the command window you are trying to run Ant in is a different window to the cmd windwo where you set up and verify that its in the path? If the PATH is updated after a cmd window is already open it won't recongnise the change. Not clear if that might be your issue.
If you are in the dir C:\Ant\bin and type "ant" does it recognise it?