From: Earnie B. <ea...@us...> - 2012-10-29 20:02:16
|
On Mon, Oct 29, 2012 at 3:30 PM, Andrew wrote: > From: Renato Silva >> How about mintty? > > I hadn't tried it, but just grabbed it and tried it, and it starts up fine > and gives me the prompt. > And mintty has the same issues as rxvt when it comes to communicating to native windows binaries. The PTY doesn't work correctly with either rxvt nor mintty and you end up with pipes and isatty() returns false. Use the native console for it MSYS. You'll be much happier in the end. -- Earnie -- https://sites.google.com/site/earnieboyd |
From: Renato S. <br....@gm...> - 2012-10-29 20:09:08
|
2012/10/29 Earnie Boyd <ea...@us...> > On Mon, Oct 29, 2012 at 3:30 PM, Andrew wrote: > > From: Renato Silva > >> How about mintty? > > > > I hadn't tried it, but just grabbed it and tried it, and it starts up > fine > > and gives me the prompt. > > > > And mintty has the same issues as rxvt when it comes to communicating > to native windows binaries. The PTY doesn't work correctly with > either rxvt nor mintty and you end up with pipes and isatty() returns > false. Use the native console for it MSYS. You'll be much happier in > the end. > > Pretty happy with mintty here. When I have some problem, like Python's and Ruby's interactive mode, I just run cmd.exe. For anything else, mintty, as you say, WJFFM. |
From: Maximus5 <Con...@gm...> - 2012-10-29 20:23:48
|
Renato Silva <br.renatosilva@...> writes: >> And mintty has the same issues as rxvt when it comes to communicating >> to native windows binaries. The PTY doesn't work correctly with >> either rxvt nor mintty and you end up with pipes and isatty() returns >> false. Use the native console for it MSYS. You'll be much happier in >> the end. > > > Pretty happy with mintty here. When I have some problem, like Python's > and Ruby's interactive mode, I just run cmd.exe. For anything else, > mintty, as you say, WJFFM. 1. May I recommend to use ConEmu as local terminal for MSYS/MinGW? http://sourceforge.net/projects/conemu/ It is ready for bash and does not have PTY problems. Here is discussion thread about it http://thread.gmane.org/gmane.comp.gnu.mingw.user/40188/focus=40196 2. As for solution for your problem with immediate "exit" I strongly recommend to use Process Monitor (from sysinternals). Run it and set up filter for sh.exe/bash.exe. It will show all files, which bash reads/finds during startup. >From this log you may find some "profile" file, which leads to "exit" regards |
From: Renato S. <br....@gm...> - 2012-10-30 03:30:12
|
2012/10/30 Andrew <no...@sh...> > cd ~ just put me/kept me in the MSYS install directory, which when in the > rxvt was the root. > > 1. do you get the same exit result with both bash and bash --login -i? Because the latter is what sets your ~ to something not /, in your case it should be E:\MSYS\1.0\home\<your-login>. 2. What if you just double click bash.exe? If it closes immediately, try creating a .bash_logout in the same directory where you got .profile working, then echo a customized logout message. Then create a shotcut to bash.exe, putting the path within quotes and then a space and "--login -i" (without the quotes). The intention is to see how it behaves when a window console is created *for running* bash (in the shortcut and directly clicking the exe) instead of when it already exists. > That's where I have my little .profile with just the echo in it, and it > gets > executed when I run bash from cmd, rxvt, or mintty. It's just that in rxvt > and mintty, it leaves me sitting in bash.. but run from cmd.exe I get my > echo line, then a prompt with "exit" on it, and I'm back at the DOS prompt, > like: > > L:\MSYS>bash > This is my MSYS BASHRC file! > bash-3.1$ exit > > L:\MSYS> > O.o > Here is the list of paths after I've removed DLLs under C:\Windows and > registry keys... > I'm not sure if the last few lines trying to access MSYS\unknown\... are > maybe indicating something is not right? > > Also, sorry if there's any confusion, I have another installation on > another > drive where I'd simply extracted the MSYS tar file into the root of the > MSYS > directory, thus my bin was MSYS\bin and under rxvt it was just /bin - thus > my path. (whereas on the E: drive I followed Earnie Boyd's "Configuring and > Using mingw-get" including the moving MSYS to the root in profile.xml) > > C: > C:\ > C:\Program Files (x86) > C:\Program Files (x86)\Bonjour > C:\Program Files (x86)\Bonjour\mdnsNSP.dll > C:\Users\andrew\AppData\Local\Temp > C:\Users\andrew\AppData\Local\Temp\* > C:\Windows > C:\Windows\Globalization > C:\Windows\Globalization\Sorting > C:\Windows\Globalization\Sorting\SortDefault.nls > C:\Windows\Prefetch\BASH.EXE-45D3AFFF.pf > C:\Windows\System32 > E: > E:\ > E:\MSYS > E:\MSYS\* > E:\MSYS\.termcap > E:\MSYS\1.0 > E:\MSYS\1.0\.bash_history > E:\MSYS\1.0\.bashrc > E:\MSYS\1.0\.inputrc > E:\MSYS\1.0\.inputrc.exe > E:\MSYS\1.0\bin > E:\MSYS\1.0\bin\bash > E:\MSYS\1.0\bin\bash.exe > E:\MSYS\1.0\bin\DNSAPI.dll > E:\MSYS\1.0\bin\fltlib.dll > E:\MSYS\1.0\bin\Iphlpapi.DLL > E:\MSYS\1.0\bin\msys-1.0.dll > E:\MSYS\1.0\bin\msys-regex-1.dll > E:\MSYS\1.0\bin\msys-termcap-0.dll > E:\MSYS\1.0\bin\netapi32.DLL > E:\MSYS\1.0\bin\netutils.dll > E:\MSYS\1.0\bin\SAMCLI.DLL > E:\MSYS\1.0\bin\SAMLIB.dll > E:\MSYS\1.0\bin\srvcli.dll > E:\MSYS\1.0\bin\VERSION.dll > E:\MSYS\1.0\bin\WINNSI.DLL > E:\MSYS\1.0\bin\wkscli.dll > E:\MSYS\1.0\bin\wsock32.DLL > E:\MSYS\1.0\etc > E:\MSYS\1.0\etc\fstab > E:\MSYS\1.0\etc\termcap > E:\MSYS\unknown > E:\MSYS\unknown\andrew > E:\MSYS\unknown\andrew.exe > 3. Try deleting this file, shouldn't be a problem but: C:\Windows\Prefetch\ BASH.EXE <http://BASH.EXE-45D3AFFF.pf> 4. Why don't you install MinGW and MSYS with mingw-get, it's simply easy, no need to go for manual steps. |
From: Renato S. <br....@gm...> - 2012-10-30 03:32:19
|
2012/10/30 Renato Silva <br....@gm...> > > 3. Try deleting this file, shouldn't be a problem but: C:\Windows\Prefetch\ > BASH.EXE <http://BASH.EXE-45D3AFFF.pf> > > I mean BASH.EXE* (anything with such name pattern). |
From: Keith M. <kei...@us...> - 2012-11-04 09:54:28
|
On 03/11/12 18:22, Andrew wrote: > Also, it's interesting that when I run just bash, it only runs the .bashrc > file in msys/1.0/ and none of my .bash_logout files - when I run it with the > args, it doesn't run any of my .bashrc files, but it does run my > .bash_logout file in msys/1.0/home/user/ What's so interesting about bash behaving *exactly* as documented? ~/.bashrc is read automatically, *only* by *non-login* shells; login shells read ~/.profile or ~/.bash_profile instead; (if you want them to read ~/.bashrc, then you must source it *explicity* from the applicable profile file. ~/.bash_logout is read *only* by *login* shells, on exit. You should read the bash manpage; google an online copy, if you aren't able to read the local msys-bash-doc copy, (as you won't be able to, if you can't get MSYS to run). -- Regards, Keith. |
From: Renato S. <br....@gm...> - 2012-11-04 17:22:51
|
2012/11/4 Keith Marshall <kei...@us...> > What's so interesting about bash behaving *exactly* as documented? > > ~/.bashrc is read automatically, *only* by *non-login* shells; login > shells read ~/.profile or ~/.bash_profile instead; (if you want them to > read ~/.bashrc, then you must source it *explicity* from the applicable > profile file. > > ~/.bash_logout is read *only* by *login* shells, on exit. > > You should read the bash manpage; google an online copy, if you aren't > able to read the local msys-bash-doc copy, (as you won't be able to, if > you can't get MSYS to run). > > I personally couldn't understand the exact differences between the concepts of login and interactive sessions, even after reading the man page.By the way I can't install bash man here: $ mingw-get install msys-bash-doc mingw-get.exe: *** ERROR *** Get package: http://prdownloads.sourceforge.net/mingw/bash-3.1.17-4-msys-1.0.16-doc.tar.lzma?download: download failed mingw-get.exe: *** ERROR *** Get package: http://prdownloads.sourceforge.net/mingw/bash-3.1.17-4-msys-1.0.16-doc.tar.lzma?download: download failed install: bash-3.1.17-4-msys-1.0.16-doc.tar.lzma mingw-get.exe: *** ERROR *** required package file is not available mingw-get.exe: *** ERROR *** cannot install bash-3.1.17-4-msys-1.0.16-doc.tar.lzma mingw-get.exe: *** ERROR *** due to previous download failure |
From: Keith M. <kei...@us...> - 2012-11-04 17:43:23
|
On 04/11/12 17:22, Renato Silva wrote: > I personally couldn't understand the exact differences between the concepts > of login and interactive sessions, even after reading the man page. Traditionally, on *nix, the login shell is the top-level shell created for you, when you log in to the system; a non-login interactive shell is any secondary interactive shell you launch from that. When you close a non-login shell, you are returned to its parent; when you close a login shell, you are logged off the system -- your connection to the host is terminated. For our purposes, a login shell is created when you start bash, (or sh), with the --login option; omit that option, and you get a non-login shell. > By the way I can't install bash man here: > $ mingw-get install msys-bash-doc > mingw-get.exe: *** ERROR *** Get package: > http://prdownloads.sourceforge.net/mingw/bash-3.1.17-4-msys-1.0.16-doc.tar.lzma?download: > download failed > ... WJFFM. Something blocked your download. Eliminate the cause of that, and try again. -- Regards, Keith. |
From: Renato S. <br....@gm...> - 2012-11-04 18:12:25
|
2012/11/4 Keith Marshall <kei...@us...> > On 04/11/12 17:22, Renato Silva wrote: > > I personally couldn't understand the exact differences between the > concepts > > of login and interactive sessions, even after reading the man page. > > Traditionally, on *nix, the login shell is the top-level shell created > for you, when you log in to the system; a non-login interactive shell is > any secondary interactive shell you launch from that. When you close a > non-login shell, you are returned to its parent; when you close a login > shell, you are logged off the system -- your connection to the host is > terminated. > > For our purposes, a login shell is created when you start bash, (or sh), > with the --login option; omit that option, and you get a non-login shell. > > Thanks for the clear explanation! > > By the way I can't install bash man here: > > $ mingw-get install msys-bash-doc > > mingw-get.exe: *** ERROR *** Get package: > > > http://prdownloads.sourceforge.net/mingw/bash-3.1.17-4-msys-1.0.16-doc.tar.lzma?download > : > > download failed > > ... > > WJFFM. Something blocked your download. Eliminate the cause of that, > and try again. > > Ah sorry, that was because I didn't elevate the privileges. I have successfully installed with mingw-get install msys-bash, even though I thought all sub-components (bin,doc,lic) were already installed. |
From: Keith M. <kei...@us...> - 2012-11-04 21:55:32
|
On 04/11/12 18:11, Renato Silva wrote: >> For our purposes, a login shell is created when you start bash, (or sh), >> with the --login option; omit that option, and you get a non-login shell. > > Thanks for the clear explanation! You're welcome. FWIW, it's a side effect of this that leads me to speculate that the OP may be bypassing msys.bat, and failing to start bash under SysWOW64, (which is necessary on his 64-bit Win-7 system): msys.bat not only takes care of the SysWOW64 requirement; it also always starts a login shell, yet the OP first reported a condition symptomatic of a non-login shell. > [re: failure to mingw-get install msys-bash-doc] > Ah sorry, that was because I didn't elevate the privileges. The user running mingw-get *must* have full access privilege throughout the MinGW and MSYS sysroot trees. If you want any user to be able to run mingw-get, you *must* grant appropriate privilege to all users; otherwise you must always run mingw-get as a suitably privileged user. > I have successfully installed with mingw-get install msys-bash, ... So now, if you've also done (at some stage within the lifetime of your current installation): $ mingw-get install msys-man you should be able to read the bash manpage locally, from the MSYS shell, (internally using "less" as the pager): $ man bash > even though I thought all sub-components (bin,doc,lic) were already > installed. Normally, only the core *binary* components are installed by default; if you want anything else, you need to install it explicitly, (and this includes some less frequently used binary "-ext" components). -- Regards, Keith. |
From: Earnie B. <ea...@us...> - 2012-11-05 13:28:31
|
On Sun, Nov 4, 2012 at 4:39 AM, Keith Marshall wrote: > On 03/11/12 18:22, Andrew wrote: >> From: Renato Silva [mailto:br....@gm...] >> Sent: Tuesday, October 30, 2012 9:33 AM >>> Those exit lines you pasted early look just like if you had typed >>> the exit command, which makes me wonder if for some crazy season >>> bash is just receiving that command from standard input. > > Much more likely: bash is seeing EOF immediately on stdin, (or doesn't > have any open stdin), at start up time; when run interactively, bash > will echo 'exit' when a non-login session sees EOF on stdin, (or > 'logout', in the case of a login session). > >> It certainly *seems* to act almost exactly as if I'd typed it... :-/ >> (except for the speed, and of course for the fact that I don't touch the >> keyboard!) I'm still not sure if that can somehow point to a solution - if >> I'm doing it subconsciously I'll likely need a shrink instead.;) > > That's unlikely; more likely, is my explanation above. The question > then becomes: why is stdin at EOF on start up? > > Please tell us *exactly* how you are attempting to start MSYS bash. > IIRC, you stated in a previous post that you are running on 64-bit Win7; > that may be important, since on this platform, MSYS bash needs to run > under SysWOW64. If you are bypassing msys.bat, you need to ensure that > this requirement is fulfilled. The 32bit cmd vs 64bit cmd doesn't matter. I am able to start the shell from the 64bit cmd without issue. -- Earnie -- https://sites.google.com/site/earnieboyd |
From: Renato S. <br....@gm...> - 2012-11-05 14:34:56
|
2012/11/5 Earnie Boyd <ea...@us...> > I have already stated that I have no issue doing this on my Win64 > 64bit I7 laptop. > > Sorry I didn't remember, but I still think the 64-bit thing may be related, specially after Keith's post. > c:\opt\mingw\msys\1.0\bin\sh --login -i > > WJFFM. This has to be an environment issue. Maybe even a local > specific OS is causing this exit. The OP is using bash instead of the > recommended sh but that shouldn't matter; if it is the bash we > distribute. > > Where does it say to not use bash and the reason it is included after all? Either way, they're exactly the same file: $ diff /bin/sh.exe /bin/bash.exe => (no output) Also, you sound like a MinGW developer, are you? Because I'm still surprised with the ';' thing, sorry for the sincerity. > -- > Earnie > -- https://sites.google.com/site/earnieboyd > > > ------------------------------------------------------------------------------ > LogMeIn Central: Instant, anywhere, Remote PC access and management. > Stay in control, update software, and manage PCs from one command center > Diagnose problems and improve visibility into emerging IT issues > Automate, monitor and manage. Do more in less time with Central > http://p.sf.net/sfu/logmein12331_d2d > _______________________________________________ > MinGW-users mailing list > Min...@li... > > This list observes the Etiquette found at > http://www.mingw.org/Mailing_Lists. > We ask that you be polite and do the same. Disregard for the list > etiquette may cause your account to be moderated. > > _______________________________________________ > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users > Also: mailto:min...@li...?subject=unsubscribe > |
From: Earnie B. <ea...@us...> - 2012-11-05 14:59:42
|
On Mon, Nov 5, 2012 at 9:34 AM, Renato Silva wrote: > 2012/11/5 Earnie Boyd <ea...@us...> >> >> I have already stated that I have no issue doing this on my Win64 >> 64bit I7 laptop. >> > > Sorry I didn't remember, but I still think the 64-bit thing may be related, > specially after Keith's post. > >> >> c:\opt\mingw\msys\1.0\bin\sh --login -i >> >> WJFFM. This has to be an environment issue. Maybe even a local >> specific OS is causing this exit. The OP is using bash instead of the >> recommended sh but that shouldn't matter; if it is the bash we >> distribute. >> > > Where does it say to not use bash and the reason it is included after all? It is implied from the use of msys.bat. > Either way, they're exactly the same file: > $ diff /bin/sh.exe /bin/bash.exe => (no output) > Which is why I stated "if it is the bash we distribute". > Also, you sound like a MinGW developer, are you? Because I'm still surprised > with the ';' thing, sorry for the sincerity. https://sourceforge.net/potm/potm-2005-09.php -- Earnie -- https://sites.google.com/site/earnieboyd |
From: Keith M. <kei...@us...> - 2012-11-05 16:18:27
|
On 05/11/12 13:28, Earnie Boyd wrote: > The 32bit cmd vs 64bit cmd doesn't matter. I am able to start the > shell from the 64bit cmd without issue. Well, it used not to be that way, else why did Tuomo Latto devote his energy to developing the patch to msys.bat, to ensure it would always restart itself under SysWOW64 when invoked from the 64-bit cmd? However, I must defer to your experience, since the Win7 delivered pre-installed on my 3-month old 64-bit laptop survived only long enough for me to save a restore DVD image set, before I blitzed it into oblivion, and installed 64-bit Linux Mint Debian Edition. -- Regards, Keith. |
From: Earnie B. <ea...@us...> - 2012-11-05 16:59:49
|
On Mon, Nov 5, 2012 at 11:18 AM, Keith Marshall wrote: > On 05/11/12 13:28, Earnie Boyd wrote: >> The 32bit cmd vs 64bit cmd doesn't matter. I am able to start the >> shell from the 64bit cmd without issue. > > Well, it used not to be that way, else why did Tuomo Latto devote his > energy to developing the patch to msys.bat, to ensure it would always > restart itself under SysWOW64 when invoked from the 64-bit cmd? > I think that is dependent on using the recursiveness .bat file. Starting directly on the command line works just fine. > However, I must defer to your experience, since the Win7 delivered > pre-installed on my 3-month old 64-bit laptop survived only long enough > for me to save a restore DVD image set, before I blitzed it into > oblivion, and installed 64-bit Linux Mint Debian Edition. I debated on doing that. I'm also debating on the upgrade to Windows 8 that I can get for $30 US or buying another PC with it installed already or perhaps use VirtualBox. -- Earnie -- https://sites.google.com/site/earnieboyd |
From: Andrew <no...@sh...> - 2012-11-05 19:35:37
|
From: Renato Silva [mailto:br....@gm...] Sent: Saturday, November 03, 2012 6:01 PM > Well, where are those files at all? They're neither attached nor in your linked > website. All the files are on the website, sorry I didn't want to type in the whole URL just to avoid harvesting stuff... all the files are under members.shaw.ca/notes/ as indicated and with the exact filenames. I tried accessing a few after I got this email but had no problem. Please let me know if you're still having trouble, I'd be happy to email them to you or whatever (assuming you're even interested in looking at them) - I didn't want to attach too much junk to the email list. Thanks, Andrew |
From: Renato S. <br....@gm...> - 2012-11-05 21:25:11
|
2012/11/5 Andrew <no...@sh...> > From: Renato Silva [mailto:br....@gm...] > Sent: Saturday, November 03, 2012 6:01 PM > > > Well, where are those files at all? They're neither attached nor in your > linked > > website. > > All the files are on the website, sorry I didn't want to type in the whole > URL just to avoid harvesting stuff... all the files are under > members.shaw.ca/notes/ as indicated and with the exact filenames. I tried > accessing a few after I got this email but had no problem. > > Please let me know if you're still having trouble, I'd be happy to email > them to you or whatever (assuming you're even interested in looking at > them) > - I didn't want to attach too much junk to the email list. > > http://i.imgur.com/rIuzc.png |
From: Earnie B. <ea...@us...> - 2012-11-06 13:10:39
|
On Mon, Nov 5, 2012 at 4:24 PM, Renato Silva wrote: > > > 2012/11/5 Andrew <no...@sh...> >> >> From: Renato Silva [mailto:br....@gm...] >> Sent: Saturday, November 03, 2012 6:01 PM >> >> > Well, where are those files at all? They're neither attached nor in your >> linked >> > website. >> >> All the files are on the website, sorry I didn't want to type in the whole >> URL just to avoid harvesting stuff... all the files are under >> members.shaw.ca/notes/ as indicated and with the exact filenames. I tried >> accessing a few after I got this email but had no problem. >> >> Please let me know if you're still having trouble, I'd be happy to email >> them to you or whatever (assuming you're even interested in looking at >> them) >> - I didn't want to attach too much junk to the email list. >> > > http://i.imgur.com/rIuzc.png "and with the exact filenames" I had to read the previous mails in the thread to find those but they are present when given. -- Earnie -- https://sites.google.com/site/earnieboyd |
From: Renato S. <br....@gm...> - 2012-11-20 20:31:12
|
2012/11/4 Keith Marshall <kei...@us...> > > Traditionally, on *nix, the login shell is the top-level shell created > for you, when you log in to the system; a non-login interactive shell is > any secondary interactive shell you launch from that. When you close a > non-login shell, you are returned to its parent; when you close a login > shell, you are logged off the system -- your connection to the host is > terminated. > > For our purposes, a login shell is created when you start bash, (or sh), > with the --login option; omit that option, and you get a non-login shell. Hmm, just to be sure if I understand it correctly. So historically, the --login option has been used in unix-like systems to inform bash that it is the main, top-level interactive session. Or is it possible, and does it make sense, to a login session to be non-interactive? If not, then "bash --login --interactive" is redundant, right? In MSYS, however, since there's no host to disconnect from, does the --login option make any difference besides the different initialization scripts that are loaded? Or in other words, what's the "correct" use of --login in MSYS? Is there anything else than these scripts that is done differently bewteen --login and --interactive, both in the unixies and MSYS? |
From: Earnie B. <ea...@us...> - 2012-11-21 13:48:32
|
On Tue, Nov 20, 2012 at 3:30 PM, Renato Silva wrote: > 2012/11/4 Keith Marshall >> >> >> Traditionally, on *nix, the login shell is the top-level shell created >> for you, when you log in to the system; a non-login interactive shell is >> any secondary interactive shell you launch from that. When you close a >> non-login shell, you are returned to its parent; when you close a login >> shell, you are logged off the system -- your connection to the host is >> terminated. >> >> For our purposes, a login shell is created when you start bash, (or sh), >> with the --login option; omit that option, and you get a non-login shell. > > > Hmm, just to be sure if I understand it correctly. So historically, the > --login option has been used in unix-like systems to inform bash that it is > the main, top-level interactive session. Or is it possible, and does it make > sense, to a login session to be non-interactive? If not, then "bash --login > --interactive" is redundant, right? > > In MSYS, however, since there's no host to disconnect from, does the --login > option make any difference besides the different initialization scripts that > are loaded? Or in other words, what's the "correct" use of --login in MSYS? > Is there anything else than these scripts that is done differently bewteen > --login and --interactive, both in the unixies and MSYS? Are you not capable of searching the internet for the answers? http://www.gnu.org/software/bash/manual/html_node/Invoking-Bash.html http://www.gnu.org/software/bash/manual/html_node/Interactive-Shells.html#Interactive-Shells -- Earnie -- https://sites.google.com/site/earnieboyd |
From: Renato S. <br....@gm...> - 2012-11-22 05:38:43
|
2012/11/21 Earnie Boyd <ea...@us...> > Are you not capable of searching the internet for the answers? How about you, are you not capable of knowing what ';' does? |
From: Andrew <no...@sh...> - 2012-12-04 23:18:18
|
From: Renato Silva [mailto:br....@gm...] Sent: Wednesday, November 21, 2012 9:47 PM > Hi Andrew, did you get any other 64-bit (or even 32-bit) WIndows installation to reproduce the problem? No, unfortunately I don't have any other 64-bit Windows to test on, but I have used MinGW and MSYS on my old 32-bit windows without any problems before. > Also, just random guessing, but is cmd.exe (both 64 and 32) running in some compatibility > mode (you can check in the file properties)? Neither of the cmd.exe's have compatibility mode checked in the file properties. > Have you ever seen it working before? If so, try to make a list, not necessarily one that > makes sense, of changes that happened since then, you may find the cause there. I'm not 100% sure as I installed it a while back shortly after installing Windows 7. It may have worked then, I don't recall if I tried opening a shell or not. :-/ There have been a ton of things installed since then, so it's hard to say. > However, at this point of time (I thought you just gave up or fixed it without feedback), > I would seriously consider debugging MSYS. Ya, sorry, just busy, but didn't give up... I might give that a shot.. Regardless, thanks again for all your help. :) |
From: Earnie B. <ea...@us...> - 2012-12-05 12:34:49
|
On Tue, Dec 4, 2012 at 6:18 PM, Andrew <no...@sh...> wrote: >> Have you ever seen it working before? If so, try to make a list, not > necessarily one that >> makes sense, of changes that happened since then, you may find the cause > there. > > I'm not 100% sure as I installed it a while back shortly after installing > Windows 7. It may have worked then, I don't recall if I tried opening a > shell or not. :-/ There have been a ton of things installed since then, > so it's hard to say. The list of programs at http://cygwin.com/faq/faq.using.html#faq.using.bloda may be interfering. -- Earnie -- https://sites.google.com/site/earnieboyd |