I have trouble setting up my virtualenv to work correctly in windows.
I'm using the latest (1.9) msysgit console to do my normal work and installed virtualenv, virtualenvwrapper and virtualenvwrapper-win via pip. It works correctly in the normal cmd, but msysgit just displays
sh.exe": mkvirtualenv: command not found
I can use the normal virtualenv, but it's cumbersome and additionally ignores my set variables of %WORKON_HOME% and %PROJECT_HOME% to seperate my envs and projects folder. Both works in cmd.exe.
Any idea?
The problem is that msysgit is not a full MSYS install. It only contains what is necessary for git to work. You have a few options: (1) Install the full, real MSYS/MINGW32 environment (not recommended why have two copies installed) or (2) install the missing piece(s).
Depending on which version of msysgit you have installed the missing pieces seem to vary, but at the very least you need to download a copy of mktemp.exe. Some users have reported also needing fmt.exe.
You may need to create a "MSYSTEM" environment variable and set it to the string "MINGW32" (which should tell virtualenvwrapper to configure paths for windows even though being run from a unix shell -- i.e.: Scripts dir instead of bin dir). And "MSYS_HOME" should be set to where msysgit is installed (perhaps add the line export MSYS_HOME = /c/Program\ Files\ \(x86\)/Git to .bashrc). I don't recall offhand if the msysgit installer sets these correctly (or at all).
Related
I have some Unix Executable Files in a paticular directory, say /Users/myUserName/Developer/sdcc/bin/.
I find I must get into this directory using cd before running that command, or it complains zsh: command not found.
But it can be of inconvenience. I know the commands can be used in any directory if it's installed by Homebrew. How can I do the same thing?
Homebrew usually links the necessary executables to /usr/local/bin directory, which should be in your $PATH. Thus, when you execute a command like sdcc, your shell will seek through the $PATH directories, and when it looks at /usr/local/bin, it will find sdcc, follow the link and execute it.
Some packages do not perform this linking, which means you cannot execute them without knowing where they are. You can ask Homebrew to tell you where a package is installed: brew --prefix <formula>, where <formula> is the package name (e.g. brew --prefix sdcc). The executable files will normally be under a bin subdirectory. For example, brew --prefix sdcc would likely tell you something like /usr/local/opt/sdcc; then you can invoke sdcc using /usr/local/opt/sdcc/bin/sdcc, without having to cd there. You could also put /usr/local/opt/sdcc/bin into your $PATH directly, though I do not recommend it. Another alternative is to create your own bin (mine is in $HOME/.local/bin), put it in $PATH, and link there (ln -s <source> $HOME/.local/bin/) any executables you wish your shell to easily find.
However, with Homebrew packages, I strongly suggest you do not try to imitate Homebrew by yourself, by installing things in Homebrew's domain. You can confuse Homebrew and create problems. Instead, let Homebrew do it.
If you need to install a package on a different OS than the one you are downloading at, you may need to first find out the bottle tag for the target (installation) computer. For example, for Big Sur, it is big_sur. See brew info --json <formula>, under bottle.stable.files you should find the bottle tags. Use --bottle-tag <tag> in step 1 and 2 to select the right OS.
Use brew fetch --deps <formula> to download (but not install) a package, including its dependencies. If you use the --verbose flag, Homebrew will tell you where it downloaded each of the files.
If you haven't used --verbose and still want to know where the downloaded files are: brew deps <formula> will list all the packages it depends on. If a package needs to be compiled, you may need to also use the --include-build option. brew --cache <formula> will show you where a package file is downloaded.
If you need to copy a package file to another computer, you should find out where the Homebrew would expect to find it: use brew --cache --force-bottle <formula> on the target computer, and copy the package file there. Don't forget to do that for each dependency package as well.
After that, brew install <formula> will install from cache.
The only part of this process that needs internet connection is the first step, brew fetch.
For Unix (which MacOS is a family member) and Unix-like (eg. Linux) operating systems the thing that controls this feature is the PATH environment variable.
To know which folders allow you to run programs without cd-ing into them or prefix ./ to your program name you can print out the value of PATH:
echo $PATH
On my machine it prints out:
/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin:/Users/slebetman/bin:/opt/homebrew/bin
There are two things to notice:
The string is a list of folder paths separated by :
There is a path listed as /opt/homebrew. Presumably this is where homebrew installs command-line programs.
Copying your program/script into any of the folders listed in PATH will allow you to use it like any installed/built-in command. This is what it means to install command-line programs on Unix. It's that simple.
There is another thing to notice: I have in my PATH the folder /Users/slebetman/bin. This is my own personal standard - probably not invented by me but one I adopted from my college days - for installing my own programs. I have this ~/bin folder on all my Unix and Linux machines. It is where I keep my personal collection of scripts that I've written or collected over a lifetime.
Having a personal ~/bin folder is nice because you don't need sudo permission to write to it. Also, if you buy a new PC/Mac you can just copy the folder to your new machine and all the scripts you've gotten used to now exist on the new machine. Better yet, you can manage the folder with git and sync it with github/gitlab/bitbucket to make it easy to keep all your computers updated.
Since PATH is a standard environment variable you can easily modify it to add your own folder. Just add the following in your .profile or .zshrc or .bashrc file (depending on your shell) to add your own bin folder to PATH:
export PATH=$PATH:$HOME/bin
The command above simply says add $HOME/bin to PATH and export it so that other programs will inherit the new PATH variable.
In your case you can even do something like:
export PATH=$PATH:/path/to/your/sdcc/bin
to have all your SDCC commands work like regular commands.
I've tried/checked related posts but I can't find what's stopping my Windows Subsystem for Linux from running conda.
These paths (I have verified that they are correct and exist) are in my PATH.
/mnt/c/Users/user/Anaconda3:
/mnt/c/Users/user/Anaconda3/Library/mingw-w64/bin:
/mnt/c/Users/user/Anaconda3/Library/usr/bin:
/mnt/c/Users/user/Anaconda3/Library/bin:
/mnt/c/Users/user/Anaconda3/Scripts
Note that I added the new lines so that it is more readable, the spaces aren't actually present in my PATH.
When I run conda --version on command prompt I get conda 4.7.12, but I get this error when I run the same thing on Linux: conda:command not found
Also, I tried closing and opening my terminal and shifting the paths to the front of PATH (not that it matters but I was desperate), both didn't help.
Already referred to:
How to run Conda?
conda command not found even though path is exported
Anyone has any idea?
I'm using cygwin installed on Windows 10 and trying to access awscli from it.
I used pip install awscli to install awscli. This installed awscli. I then tried to run only aws to see if it is installed and I get the following error:
-bash: /cygdrive/c/Program Files/Anaconda2/Scripts/aws: C:\Program: bad interpreter: No such file or directory
I'm not sure why this is happening. Any help in this regard would be highly apreciated.
This is still an issue even with the latest version of AWS cli. So after some trial and error I found a pretty good workaround that will not make you switch your favorite shell.
First, make sure python is on your PATH. That is from anywhere in the system you can just run python and it work.
Find the aws script and open it for editing (for me it was located in c:\Program Files\Python36\Scripts\aws) and change the hashbang (that would be the first line in the script) to #!python.exe. For me it was set to #!c:\Program Files\Python36\python.exe. That space in the middle of Program Files caused the issue when that path got converted to Linux like path. Changing it to #!python.exe sidesteps the issue.
When you update AWS cli, repeat the workaround.
PS. You could also avoid this issue by installing python somewhere in a folder without spaces in path. That requires to reconfigure your system, so I did not do that myself.
I would install the standard python and ensure it is coming up first in your path with which python and which pip. Path issues like this are due to mixing and matching executables targeting different platforms in my experience. Certain commands do not implement functionality to convert paths from Windows to Linux and back (it appears your specific commands are failing on spaces).
Since you say you are on Windows 10, if you have the anniversary edition, I would recommend Windows Subsystem for Linux over cygwin. You will likely see less Windows issues on WSL since it uses the exact same ubuntu packages you would use on Linux instead of the cygwin port and maps them low level to the NT Kernel.
The Problem comes from "Program Files" having a space. This is something that is related to cygwin (I encountered the same error with git bash on windows). In a script I had something like this:
#!/c/Program Files/some_program/executable.exe
Escaping the space with a backslash or using quotes didn't work.
The solution is to use the DOS' short filename:
Progra~1 for "Program Files"
Progra~2 for "Program Files (x86)"
So my line would turn into:
#!/c/Progra~1/some_program/executable.exe
In Windows:
cd .. to go to home directory which shows pwd as /.
Now, cd to /cygdrive/c/Program\ Files/Anaconda2/Scripts
Now, run: python aws configure
Example:
user#user /cygdrive/c/Program Files/Anaconda2/Scripts
$python aws configure
I have just downloaded the latest Git for Windows installer, v2.4. It appears to want to install to the standard Windows "Program files" (with-spaces-in-name) directory.
Since I have all my development code in a folder called (simply) "/bin" -- I want to see if there's a command line option or parameter to change the install directory.
In my case, these days I use a environment variable such as GIT_HOME for important software like git; so it would be useful if there was a way to apply that to things like git commands, etc once I have the program installed.
possibly related:
How do I change the directory in Git Bash with Git for Windows?
I also came across a few questions asking: "whereis git". That's answered above, however I take that as an indicator that others may want git somewhere else too.
To start the installer with a different installation path you can open a CMD terminal in the same directory as the installer executable and pass in an option parameter of /DIR="x:\dirname"
For instance, if you have version 2.17.0 for Windows 64bit and you want to install git to D:\git, you would run:
Git-2.17.0-64-bit.exe /DIR="D:\git"
The installer will launch as usual and you need to walk through the other options, but the install location will be the path specified.
Since I just ran into this problem because my SSD is filling up, I figured I'd share the solution I came to on Windows 11 with Git v. 2.37.2.
The best way I could figure was to uninstall Git, then in CMD Prompt use the suggested command from the Git website with an appended --location/ -l flag:
winget install --id Git.Git -e --source winget --location [drive:/directory]
where [drive:/directory] is your target for the install. Had no issues and verified it worked with a project.
this is what I get when I use bower init
what could be the problem??
The problem is with the terminal/console you're using to.
I ran into this same problem other day, I was using Git bash as my terminal, and trying to run this command with Node.js command prompt worked normally.
Try to use another terminal, like cmder (I really recommend this to Windows users), Node.js command prompt or even Windows cmd itself. Hope to have helped you. Best wishes!
The solution is to install GIT bash and avoid
using MinTTY and follow the documentation. Here is the solution:
Uninstall existing GIT bash Reinstall GIT bash Set up during
installation:
Select Use Git from the Windows Command Prompt
Select Checkout Windows-style, commit Unix-style line endings
Select Use Windows' default console window
Okay this works for sure -
Go to https://cygwin.com/install.html and download either the
32 or 64 bit version of Cygwin.
Run the install and install it onto one of your drives.
Run the Cygwin.bat and you will get the same command line
interface.
When you run bower init, it will work just fine. The Mintty that
comes with GIT is broken for somethings. Use the shell that comes
with Cygwin and you will be fine.
It works for me no problem. I used the 64 bit version on a Window 8 64bit OS. Good Luck!
You're most likely running C:\Program Files\Git\git-bash.exe and can instead run C:\Program Files\Git\bin\bash.exe to eliminate the issue. This avoids having to install another yet another terminal.