<p dir="ltr">I created a Cabal variable with the path to cabal\bin in the system variables area and than put that early in the Path variable </p>
<p dir="ltr">Cabal update now finds the new cabal-install </p>
<p dir="ltr">What are the pros and cons of doing this?</p>
<p dir="ltr">I have a feeling running batch scripts to set path variables might be better to avoid long path variables and to inadvertently finding the wrong files on long path variables. <br></p>
<p dir="ltr">I have also found that you want to install most/all programming platforms outside of the Program Files folder which Windows has special protections on. <br></p>
<p dir="ltr">--<br>
--</p>
<p dir="ltr">Sent from an expensive device which will be obsolete in a few months! :D</p>
<p dir="ltr">Casey<br>
    </p>
<div class="gmail_quote">On Jul 13, 2015 10:57 AM, "Michael Steele" <<a href="mailto:mikesteele81@gmail.com">mikesteele81@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>I disagree that this is a bug or misfeature in the Haskell Platform. The problem is caused by a quirk in how Windows works.<br><br>There are a few other options I didn't mention. One is to delete the global entry from the 'system' path variable and insert it into the 'user' path variable somewhere after the "%appdata%\cabal\bin" entry. The downside here is that other user accounts will be affected. Another option is to use a custom shortcut or execute a batch script which manually sets PATH variables as needed. This is the method I use personally.<br><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jul 13, 2015 at 10:01 AM, Sven Panne <span dir="ltr"><<a href="mailto:svenpanne@gmail.com" target="_blank">svenpanne@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span>2015-07-13 18:41 GMT+02:00 Michael Steele <span dir="ltr"><<a href="mailto:mikesteele81@gmail.com" target="_blank">mikesteele81@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">On Windows the 'system' path variable always has precedence over the 'user' path variable (see [1]). You will need to rename, delete, or overwrite the version of cabal.exe installed globally for the one under %appdata% to be used.<br><br><br>[1]: <a href="https://support.microsoft.com/en-us/kb/100843" target="_blank">https://support.microsoft.com/en-us/kb/100843</a></div></blockquote><div><br></div></span><div>To me that looks like a bug in the Haskell Platform installer: It puts the path to the tools shipped with the platform into the the system PATH and the path to the user-installed tools (i.e. the stuff below %APPDATA%) into the user part of the PATH. This way, you will always get the shipped alex/cabal/happy/HsColour, not the new stuff. This is a bit like putting e.g. /usr/bin before your $HOME/bin on *nices, which is exactly the wrong way round.</div><div><br></div><div>Furthermore, I've just seen that there is a 'C:\Program Files\Haskell\bin' at the start of my system PATH, pointing to nowhere. Is this a remnant of former GHC/platform installations? No clue where this comes from...</div></div></div></div>
</blockquote></div><br><br clear="all"><br>-- <br><div><div>-- Michael Steele</div></div>
</div>
</blockquote></div>