Why Isn't Git Bash Transforming The Path to *Nix Notation for My Python Installation

Why isn't git bash transforming the path to *nix notation for my python installation?

Open a new CMD, and set the minimal PATH you need:

set PATH=C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem
set GIT_HOME=C:\Path\to\Git
set PATH=%GIT_HOME%;%GIT_HOME%\bin;%GIT_HOME%\usr\bin;%PATH%
SET PATH=C:\Users\Aerovistae\AppData\Local\Programs\Python\Python36-32;%PATH%

(Make sure python.exe is indeed in C:\Users\Aerovistae\AppData\Local\Programs\Python\Python36-32)

Then, type bash, and see if python.exe works.

You can also add your previous paths, to identify the one causing trouble.

In the OP's case, the stray leading space for the Python path was the troublemaker.

Adding a directory to the PATH environment variable in Windows

This only modifies the registry. An existing process won't use these values. A new process will do so if it is started after this change and doesn't inherit the old environment from its parent.

You didn't specify how you started the console session. The best way to ensure this is to exit the command shell and run it again. It should then inherit the updated PATH environment variable.

How do I change the default library path for R packages

See help(Startup) and help(.libPaths) as you have several possibilities where this may have gotten set. Among them are

• setting R_LIBS_USER
• assigning .libPaths() in .Rprofile or Rprofile.site

and more.

In this particular case you need to go backwards and unset whereever \\\\The library/path/I/don't/want is set.

To otherwise ignore it you need to override it use explicitly i.e. via

library("somePackage", lib.loc=.libPaths()[-1])

when loading a package.

Cannot compile Makefile using make command on Windows

I can't answer but maybe I can orient you.

First nmake is not make. It will not work with any makefile not written specifically as an nmake makefile. And it's only available on Windows. So, best to just forget it exists.

Second, it's important to understand how make works: rules in makefiles are a combination of targets/prerequisites, and a recipe. The recipe is not in "makefile" syntax, it's a shell script (batch file). So make works in tandem with the shell, to run commands. Which shell? On POSIX systems like GNU/Linux and MacOS it's very simple: a POSIX shell; by default /bin/sh.

On Windows systems it's much less simple: there are a lot of options. It could be cmd.exe. It could be PowerShell. It could be a POSIX shell, that was installed by the user. Which one is chosen by default, depends on how your version of make was compiled. That's why you see different behaviors for different "ports" of make to Windows.

So, if you look at the makefiles you are trying to use you can see they are unquestionably written specifically for a POSIX system and expect a POSIX shell and a POSIX environment. Any attempt to use a version of make that invokes cmd.exe as its default shell will fail immediately with syntax errors ("" was unexpected at this time.).

OK, so you find a version of make that invokes a POSIX shell, and you don't get that error anymore.

But then you have to contend with another difference: directory separators. In Windows they use backslash. In POSIX systems, they use forward slash and backslash is an escape character (so it's not just passed through the shell untouched). If you are going to use paths in a POSIX shell, you need to make sure your paths use forward slashes else the shell will remove them as escape characters. Luckily, most Windows programs accept forward slashes as well as backslashes as directory separators (but not all: for example cmd.exe built-in tools do not).

Then you have to contend with the Windows abomination known as drive letters. This is highly problematic for make because to make, the : character is special in various places. So when make sees a line like C:/foo:C:/bar its parser will get confused, and you get errors. Some versions of make compiled for Windows enable a heuristic which tries to see if a path looks like a drive letter or not. Some just assume POSIX-style paths. They can also be a problem for the POSIX shell: many POSIX environments on Windows map drive letters to standard POSIX paths, so C:\foo is written as /c/foo or /mnt/c/foo or something else. If you are adding paths to your makefile you need to figure out what the right mapping, if any, is and use that.

That's not even to start discussing the other differences between POSIX and Windows... there are so many.

From what you've shown above, this project was not written with any sort of portability to Windows in mind. Given the complexity of this, that's not surprising: it takes a huge amount of work. So you have these options that I can see:

1. Port it yourself to be Windows-compatible
2. Try to get it working inside cygwin (cygwin is intended to be a POSIX-style environment that runs on Windows)
3. Try to get it working in WSL
4. Install a virtual machine using VMWare, VirtualBox, etc. running a Linux distribution and build and run it there

Unfortunately I don't know much about the pros and cons of these approaches so I can't advise you as to the best course.

The route I chose, long long ago, was to get rid of Windows entirely and just use GNU/Linux. But of course that won't be possible for everyone :).

flutter doctor doesn't work on neither Command Prompt or PowerShell window?

to run flutter from the command prompt on your windows system it requires three things

1. path to the bin folder of downloaded flutter sdk
   I have downloaded and saved the sdk in my documents so for me path will be

C:\Users\mahesh_2\Documents\flutter_windows_v0.11.9-beta\flutter\bin

2. where.exe located at C:\Windows\System32

Note:you need to download git from here if you dont find path in step 3

3. git-cmd.exe located in C:\Program Files\Git\git-cmd.exe

so to simply add these three paths to your environment variables
go to system environment variables
with variable name as Path

and value as

C:\Windows\System32;C:\Program Files\Git\git-cmd.exe;C:\Users\mahesh_2\Documents\flutter_windows_v0.11.9-beta\flutter\bin

restart the command prompt and try running flutter and Voila! you should get something like this

---

Related Topics