MinGW - Minimalist GNU for Windows

2012/10/28 Andrew <notes@...>

> Hello,****
>
> ** **
>
> I installed MinGW some time back and recently uninstalled and reinstalled
> the latest version of MinGW and msys.****
>
> ** **
>
> When I tried to run msys.bat I get a "logout" on the prompt line and it
> exits. When I tried to run either sh, or bash, I get an "exit" on the
> prompt line and the shell exits immediately.****
>
> ** **
>
> I then uninstalled to install a clean msysgit. However, I get the same
> results from msys.bat, sh, and bash. However, this time I have rxvt.exe,
> which I can run without any apparent problem (and without it immediately
> exiting, of course!)****
>
> ** **
>
> I suspect maybe some left-over config file(?) from my initial installation
> in which I did something stupid, but I don't know much about this
> environment… I don't see any .bashrc or similar files, at least in my
> MinGW/msysgit directories.****
>
> ** **
>
> Any thoughts or suggestions would be much appreciated.  I pretty much
> don't know what I'm doing, so please don't hesitate to point out the
> blindingly obvious.  ;)****
>
> ** **
>
> Thanks,****
>
> ** **
>
> Andrew****
>

Hi Andrew,

I would try to install MinGW and MSYS on a totally separate folder, and be
sure to not have stuff from old installation in system path (by renaming
the old directories and taking a look on how the Windows path looks like).

My guess is that there's an exit command in some of the bash initialization
scripts, such as /etc/profile or ~/.profile, which isn't getting
overwritten or ignored in your new installations. Try to inspect those
files from rxvt, and make sure mount isn't referencing old stuff (I think
sometimes you need to reboot/logout to some mount changes to take effect).

Hi Andrew,

I would try to install MinGW and MSYS on a totally separate folder, and be
sure to not have stuff from old installation in system path (by renaming the
old directories and taking a look on how the Windows path looks like).

My guess is that there's an exit command in some of the bash initialization
scripts, such as /etc/profile or ~/.profile, which isn't getting overwritten
or ignored in your new installations. Try to inspect those files from rxvt,
and make sure mount isn't referencing old stuff (I think sometimes you need
to reboot/logout to some mount changes to take effect).

 

 

Hi,

 

Thanks for the reply, and the suggestions.

 

I tried installing MinGW into a separate directory on a completely different
drive, and in a DOS shell I set my path to simply MinGW\msys\1.0\bin and
still got the same results.. bash and sh both have "exit" on the prompt
line, and then exit.

 

I also tried installing msyscore-1.0.11-bin into a separate directory and
setting the path to simply msys\bin, and both sh and bash did the same, and
running as per the msys.bat, like: 

 

msys\bin\sh --login -i

 

I get "logout" on the prompt line and it exits. (if I actually run the
msys.bat file the window appears and goes away too fast to read)

 

The only profile I could find, as you mentioned was the /etc/profile and
didn't see anything obviously logging out or exiting, and both
/msys/etc/profile (from msyscore-1.0.11-bin) and /MinGW/msys/1.0/etc/profile
are identical.

 

In rxvt, I checked /home/andrew and the only file in there is .inputrc

 

However, from within rxvt I can run sh or bash and they load without
exiting, and running "sh --login -i" works fine too.

 

Thanks again,

 

Andrew

Em 29/10/2012 04:04, "Andrew" <notes@...> escreveu:
>
> Thanks for the reply, and the suggestions.
>
>
>
> I tried installing MinGW into a separate directory on a completely
different drive, and in a DOS shell I set my path to simply
MinGW\msys\1.0\bin and still got the same results.. bash and sh both have
"exit" on the prompt line, and then exit.
>
>
>
> I also tried installing msyscore-1.0.11-bin into a separate directory and
setting the path to simply msys\bin, and both sh and bash did the same, and
running as per the msys.bat, like:
>
>
>
> msys\bin\sh --login -i
>
>
>
> I get "logout" on the prompt line and it exits. (if I actually run the
msys.bat file the window appears and goes away too fast to read)
>
>
>
> The only profile I could find, as you mentioned was the /etc/profile and
didn't see anything obviously logging out or exiting, and both
/msys/etc/profile (from msyscore-1.0.11-bin) and
/MinGW/msys/1.0/etc/profile are identical.
>
>
>
> In rxvt, I checked /home/andrew and the only file in there is .inputrc
>
>
>
> However, from within rxvt I can run sh or bash and they load without
exiting, and running "sh --login -i" works fine too.

Aren't you installing it through mingw-get? Also, I suppose you're running
cmd.exe, so how about launching it from within rxvt, then bash? How about a
sample script that writes to some file, what happens if you double click
it, launch inside rxvt, and also from within cmd.exe? How about mintty?

On Mon, Oct 29, 2012 at 2:01 AM, Andrew wrote:
Please use text mode email to this list and use proper quoting.

>
> I tried installing MinGW into a separate directory on a completely different
> drive, and in a DOS shell I set my path to simply MinGW\msys\1.0\bin and
> still got the same results.. bash and sh both have "exit" on the prompt
> line, and then exit.
>

WJFFM, I think you need to look in your Windows environment for
potential problems.

>
>
> I also tried installing msyscore-1.0.11-bin into a separate directory and
> setting the path to simply msys\bin, and both sh and bash did the same, and
> running as per the msys.bat, like:
>
>
>
> msys\bin\sh --login -i
>
>
>
> I get "logout" on the prompt line and it exits. (if I actually run the
> msys.bat file the window appears and goes away too fast to read)
>

Again something in your Windows environment is getting in the way.

>
>
> The only profile I could find, as you mentioned was the /etc/profile and
> didn't see anything obviously logging out or exiting, and both
> /msys/etc/profile (from msyscore-1.0.11-bin) and /MinGW/msys/1.0/etc/profile
> are identical.
>
>
>
> In rxvt, I checked /home/andrew and the only file in there is .inputrc
>

It is not recommended to use rxvt anymore.  The newest versions of
MSYS do not start it automatically.

>
>
> However, from within rxvt I can run sh or bash and they load without
> exiting, and running "sh --login -i" works fine too.

Another indication that something in your Windows environment is
getting in the way.

-- 
Earnie
-- https://sites.google.com/site/earnieboyd

Thanks for the reply.

On Mon, Oct 29, 2012 at 5:56 AM, Earnie Boyd wrote:
> On Mon, Oct 29, 2012 at 2:01 AM, Andrew wrote:
> Please use text mode email to this list and use proper quoting.

My apologies.

> > I tried installing MinGW into a separate directory on a completely
> > different drive, and in a DOS shell I set my path to simply
> > MinGW\msys\1.0\bin and still got the same results.. bash and sh both
> > have "exit" on the prompt line, and then exit.
> 
> WJFFM, I think you need to look in your Windows environment for
> potential problems.

I imagine it works for probably thousands of people ;) So surely it's
*something* on my machine.. It has even worked for me on another machine in
the past, though I only used it briefly. I don't recall if it worked when I
originally installed it on this machine.

I'm really not sure where to look though. Any idea where in the windows
environment to look for something? Or are you referring to the environment
variables? The only thing in there that I know for sure is relevant is the
path, and as I mentioned I tried setting it to just the single bin directory
without any luck.

> It is not recommended to use rxvt anymore.  The newest versions of MSYS
> do not start it automatically.

The sole reason I've used it at all is that it at least works. I've just
been trying everything I can think of... and frankly, rxvt does the job, but
I'd much rather have my setup working properly and be using msys.bat and not
rxvt as you suggest.

Thanks again,

Andrew

2012/10/29 Andrew <notes@...>

I'm really not sure where to look though. Any idea where in the windows
> environment to look for something? Or are you referring to the environment
> variables? The only thing in there that I know for sure is relevant is the
> path, and as I mentioned I tried setting it to just the single bin
> directory
> without any luck.
>

What do you mean just the single bin? Paste the output of the command below:
bash -c "echo $PATH | tr : \\n"

>
> > It is not recommended to use rxvt anymore.  The newest versions of MSYS
> > do not start it automatically.
>
> The sole reason I've used it at all is that it at least works. I've just
> been trying everything I can think of... and frankly, rxvt does the job,
> but
> I'd much rather have my setup working properly and be using msys.bat and
> not
> rxvt as you suggest.
>
>
Why don't you try my suggestions from previous messages, you haven't
answered to all of them.

From: Renato Silva [mailto:br.renatosilva@...] 
Sent: Sunday, October 28, 2012 11:26 PM

> Aren't you installing it through mingw-get?

I have tried it without (using only mingw-get-inst) and with it.

> Also, I suppose you're running cmd.exe, so how
> about launching it from within rxvt, then bash?

If I double-click rxvt, I can then run sh or bash from within it, the same
as if I run rxvt from cmd.exe

> How about a sample script that writes to
> some file, what happens if you double click it, launch inside rxvt, and
also from within 
> cmd.exe? 

I tried a very simple script that just echo'd some text to a file. It runs
fine and creates the file if I run it from rxvt or mintty, or from within
cmd.exe I type: 

sh test
or
bash test

I can't double click it since it has no extension.. 

> 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.

I wondered if anything ever wrote to something in like
c:\users\andrew\something... since that might survive uninstalls and
directory deletions - though I don't see anything obvious in there.

Thanks again for your efforts to try and help me figure this annoying little
issue out! :)


Andrew

On Mon, Oct 29, 2012 at 2:32 PM, Andrew wrote:
> Thanks for the reply.
>
> On Mon, Oct 29, 2012 at 5:56 AM, Earnie Boyd wrote:
>> On Mon, Oct 29, 2012 at 2:01 AM, Andrew wrote:
>> Please use text mode email to this list and use proper quoting.
>
> My apologies.
>
>> > I tried installing MinGW into a separate directory on a completely
>> > different drive, and in a DOS shell I set my path to simply
>> > MinGW\msys\1.0\bin and still got the same results.. bash and sh both
>> > have "exit" on the prompt line, and then exit.
>>
>> WJFFM, I think you need to look in your Windows environment for
>> potential problems.
>
> I imagine it works for probably thousands of people ;) So surely it's
> *something* on my machine.. It has even worked for me on another machine in
> the past, though I only used it briefly. I don't recall if it worked when I
> originally installed it on this machine.
>
> I'm really not sure where to look though. Any idea where in the windows
> environment to look for something?

No idea.

> Or are you referring to the environment
> variables?

Yes this is what I mean.

> The only thing in there that I know for sure is relevant is the
> path, and as I mentioned I tried setting it to just the single bin directory
> without any luck.
>

We suggest people not add the MinGW and MSYS paths to the Windows PATH
variable.  What version of Windows are you using and is it an American
version or some other locale specific release?

>> It is not recommended to use rxvt anymore.  The newest versions of MSYS
>> do not start it automatically.
>
> The sole reason I've used it at all is that it at least works. I've just
> been trying everything I can think of... and frankly, rxvt does the job, but
> I'd much rather have my setup working properly and be using msys.bat and not
> rxvt as you suggest.

The fact that it works via rxvt is rather interesting, if it isn't
going to work it shouldn't work at all but I still think you're
missing something in your environment.

What is the absolute path to sh.exe?  Does the absolute path contain spaces?

-- 
Earnie
-- https://sites.google.com/site/earnieboyd

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

2012/10/29 Andrew <notes@...>

> From: Renato Silva [mailto:br.renatosilva@...]
> Sent: Sunday, October 28, 2012 11:26 PM
>
> > Aren't you installing it through mingw-get?
>
> I have tried it without (using only mingw-get-inst) and with it.
>
> > Also, I suppose you're running cmd.exe, so how
> > about launching it from within rxvt, then bash?
>
> If I double-click rxvt, I can then run sh or bash from within it, the same
> as if I run rxvt from cmd.exe
>

Ok, but as I have asked, how about launching *cmd.exe from rxvt, then bash*?


> > 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.
>
>
So as you can have it working file with both rxvt and mintty, it seems some
odd issue with cmd.exe.


> I wondered if anything ever wrote to something in like
> c:\users\andrew\something... since that might survive uninstalls and
> directory deletions - though I don't see anything obvious in there.
>
>
Try the procmon utility, run your problematic msys.bat or whatever then
catch all file paths it reads, then export to csv, open it in some
spreadsheet editor and sort by the path column, then check what you see
there.

2012/10/29 Earnie Boyd <earnie@...>

> 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.

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 Silva [mailto:br.renatosilva@...] 
Sent: Monday, October 29, 2012 12:29 PM

> What do you mean just the single bin? Paste the output of the command
below:
> bash -c "echo $PATH | tr : \\n"

Just so you know, what I meant was that the output from the above command
is:

/bin

I just started cmd.exe and set my path (over writing all the other junk) to
the one directory before running rxvt.

> Try the procmon utility, run your problematic msys.bat or whatever then
catch all file paths
> it reads, then export to csv, open it in some spreadsheet editor and sort
by the path 
> column, then check what you see there.

Thanks to you and Maximus5 for that suggestion. I thought that should show
me for sure...

However, in the < .04 seconds it takes to run, I get ~600 lines.. but after
looking through them I still do not see anything obvious that it's trying to
read that might cause it to exit. I tried your suggestion of sorting by
path, but I still don't see anything. Maybe I'm blind. ;)

I noticed that if I put a .bashrc into /msys it seems to read and execute
it. It doesn't seem to find a .bashrc if I put it in /msys/home/<user>

Thanks,

Andrew

2012/10/29 Andrew <notes@...>

> From: Renato Silva [mailto:br.renatosilva@...]
> Sent: Monday, October 29, 2012 12:29 PM
>
> > What do you mean just the single bin? Paste the output of the command
> below:
> > bash -c "echo $PATH | tr : \\n"
>
> Just so you know, what I meant was that the output from the above command
> is:
>
> /bin
>
> I just started cmd.exe and set my path (over writing all the other junk) to
> the one directory before running rxvt.
>

Weird!


>
> > Try the procmon utility, run your problematic msys.bat or whatever then
> catch all file paths
> > it reads, then export to csv, open it in some spreadsheet editor and sort
> by the path
> > column, then check what you see there.
>
> Thanks to you and Maximus5 for that suggestion. I thought that should show
> me for sure...
>
> However, in the < .04 seconds it takes to run, I get ~600 lines.. but after
> looking through them I still do not see anything obvious that it's trying
> to
> read that might cause it to exit. I tried your suggestion of sorting by
> path, but I still don't see anything. Maybe I'm blind. ;)
>
>
Well, did you try removing the duplicated entries? I thought I didn't need
to mention that. If you can get the column properly sorted, paste it onto a
text file and run uniq in the sorted lines: echo txt | uniq.


> I noticed that if I put a .bashrc into /msys it seems to read and execute
> it. It doesn't seem to find a .bashrc if I put it in /msys/home/<user>
>
>
Do you mean an actual /msys mount point? Because there's no such a thing,
not in the standard MSYS at least, maybe in MSYS developer toolkit, not
sure though. If you just mean where MSYS is installed ok. Either way, try
~/.profile, check if the commands in it are executed when starting bash
from cmd.exe, rxvt, and mintty. For being sure where ~ is, cd ~ && pwd.
Create a ".profile" there with touch or echo, because explorer won't allow
it, you can then edit with some editor and save.

From: Renato Silva [mailto:br.renatosilva@...] 
Sent: Monday, October 29, 2012 4:10 PM

> Well, did you try removing the duplicated entries? I thought I didn't need
to mention
> that. If you can get the column properly sorted, paste it onto a text file
and run
> uniq in the sorted lines: echo txt | uniq.

I don't think it was quite that bad, but wasn't aware of uniq, and it
certainly makes it fairly clear what it gets at. I'll paste it at the
bottom.
 
> Do you mean an actual /msys mount point?

Sorry for the ambiguity, I did mean just where MSYS is installed.

> Either way, try ~/.profile, check if the commands in it are executed when
starting bash
> from cmd.exe, rxvt, and mintty. For being sure where ~ is, cd ~ && pwd.
Create a 
> ".profile" there with touch or echo, because explorer won't allow it, you
can then 
> edit with some editor and save.

cd ~ just put me/kept me in the MSYS install directory, which when in the
rxvt was the root.

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>

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

2012/10/30 Andrew <notes@...>

>  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.

2012/10/30 Renato Silva <br.renatosilva@...>

>
> 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).

Andrew <notes@...> writes:



> 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>



What is in your %COMSPEC% environment variable?



Thought, would be nice to see lines from Process Monitor log

(when "exit" triggered, of course). Upload it somewhere

and post here the link.

> -----Original Message-----
> From: Maximus5 [mailto:ConEmu.Maximus5@...]
> Sent: Monday, October 29, 2012 10:19 PM
> 
> What is in your %COMSPEC% environment variable?

C:\Windows\System32\cmd.exe

I'm on Windows 7 64 bit if I didn't say before, if it matters..  :)

> 
> Thought, would be nice to see lines from Process Monitor log
> 
> (when "exit" triggered, of course). Upload it somewhere
> 
> and post here the link.

I put the entire file up, it's not that big - only included process names
containing "bash" I put both LogBash.CSV and LogBash.PML

I wasn't sure where else to put them so I just put them at members.shaw.ca
under /notes/

I have to go for a couple days, but just wanted to get that up... in case
y'all were dying of curiosity! ;)  Will resume when I get back.. and Many
thanks for the help from you guys! :)

Andrew

On Mon, Oct 29, 2012 at 10:43 PM, Andrew <notes@...> wrote:
>
> 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)
>

I'm happy people are finding the Google doc.  See
https://docs.google.com/document/d/1z8P0ke7yF2yo05Jds4jW-GtAXcQKOr1Bfjn0vAwvVg4/edit
if you want to know what it says.  But see below.

> 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


You're missing quite a bit here.  I'll suggest you reinstall MSYS.

mingw-get install --reinstall msys

-- 
Earnie
-- https://sites.google.com/site/earnieboyd

Em 30/10/2012 05:08, "Andrew" <notes@...> escreveu:
>
> > -----Original Message-----
> > From: Maximus5 [mailto:ConEmu.Maximus5@...]
> > Sent: Monday, October 29, 2012 10:19 PM
> >
> > What is in your %COMSPEC% environment variable?
>
> C:\Windows\System32\cmd.exe
>
> I'm on Windows 7 64 bit if I didn't say before, if it matters..  :)
>
> >
> > Thought, would be nice to see lines from Process Monitor log
> >
> > (when "exit" triggered, of course). Upload it somewhere
> >
> > and post here the link.
>
> I put the entire file up, it's not that big - only included process names
> containing "bash" I put both LogBash.CSV and LogBash.PML
>
> I wasn't sure where else to put them so I just put them at members.shaw.ca
> under /notes/
>
> I have to go for a couple days, but just wanted to get that up... in case
> y'all were dying of curiosity! ;)  Will resume when I get back.. and Many
> thanks for the help from you guys! :)

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.

Another suggestion, make a diff out of the full unique file list you
mentioned above when you start bash from cmd.exe and it exits, and the list
for when you can successfully start bash (e.g. from mintty).

Yes, I'm very curious to know what's happening. So please provide feedback
on these and the previous suggestions :-)

It's a bit frustrating when you get curious and try helping someone, but
they don't share the solution or if they just gave up, like on some recent
threads around here :-/

>
> Andrew
>
>
>
------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_sfd2d_oct
> _______________________________________________
> MinGW-users mailing list
> MinGW-users@...
>
> 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:mingw-users-request@...

> -----Original Message-----
> From: Earnie Boyd [mailto:earnie@...]
> Sent: Tuesday, October 30, 2012 7:36 AM
> 
> I'm happy people are finding the Google doc.  See
> https://docs.google.com/document/d/1z8P0ke7yF2yo05Jds4jW-
> GtAXcQKOr1Bfjn0vAwvVg4/edit
> if you want to know what it says.  But see below.

Yes, it was definitely helpful as there's some uncertainty setting it up
without it.

> 
> You're missing quite a bit here.  I'll suggest you reinstall MSYS.
> 
> mingw-get install --reinstall msys
> 

I backed up my MSYS\1.0\* directory, ran the mingw-get install --reinstall
msys, and then compared the two and they're binary identical. 

Any idea what might be going on? Could I have messed something up? I think I
did the file list thing right as far as sorting in excel, dumping the column
as simple csv, and then run it through uniq.. and then removing only
registry entries and DLLs under the windows directory.

I'm just going to go give Renato's suggestion a try and will reply with
results..

Thanks :)

From: Renato Silva [mailto:br.renatosilva@...] 
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. 

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. ;)

> Another suggestion, make a diff out of the full unique file list you
mentioned above when 
> you start bash from cmd.exe and it exits, and the list for when you can
successfully start 
> bash (e.g. from mintty).

I spent some time actually taking the two files and lining them up - so that
the parts that were identical match up and you can easily see what happens
different on either side. It doesn't seem like much to me, but if you're
still willing to help, maybe you can see something in it. I'll put them up
on the same members.shaw.ca under /notes/ if you want to have a look.

> Yes, I'm very curious to know what's happening. So please provide feedback
on these and 
> the previous suggestions :-)

I tried your other suggestion, re: deleting the few bash.exe* files in the
prefetch.. no luck there.. thanks for that though.

As far as the results from just bash vs bash with the "--login -i" ..
they're slightly different, in that just bash gives me "exit" on the prompt,
and with the args, it says "logout" Also, with the args, I get user@...
and coloured prompt, whereas without I just get "bash-3.1$" as the prompt. 

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/ 

I have different .bashrc and .bash_logout files in /msys, /msys/1.0,
/msys/1.0/home/user, and even put some in /msys/1.0/bin so I can tell which
ones run.

> It's a bit frustrating when you get curious and try helping someone, but
they don't share 
> the solution or if they just gave up, like on some recent threads around
here :-/

I don't know how much more you can or are willing to help, but I do
appreciate your efforts so far!  :)

The files of the different runs (from the prompt that exits immediately and
from mintty, where I typed exit manually) I put up are:

The unique paths lists from each run
LogBash2a_paths_uniq.txt
LogBash2b-mintty_paths_uniq.txt

The two full (unmodified) csv logs from each run:
LogBash2a.CSV
LogBash2b-mintty.CSV

The two logs that I added in dummy lines to line them up (my stupid compare
program forced me to put in the first few fields, but you can see all the
times in inserted lines are identical, and they only have the first few
fields anyway..):
LogBash2a5.CSV
LogBash2b-mintty_RE-AL8.CSV

I don't know if that helps, (as it didn't seem to help me much, but maybe
you or someone else can see something..? assuming you haven't given up on me
yet..)  ;)

Thanks!

Andrew

2012/11/3 Andrew <notes@...>

> > Another suggestion, make a diff out of the full unique file list you
> mentioned above when
> > you start bash from cmd.exe and it exits, and the list for when you can
> successfully start
> > bash (e.g. from mintty).
>
> I spent some time actually taking the two files and lining them up - so
> that
> the parts that were identical match up and you can easily see what happens
> different on either side. It doesn't seem like much to me, but if you're
> still willing to help, maybe you can see something in it. I'll put them up
> on the same members.shaw.ca under /notes/ if you want to have a look.
>

Actually I meant the diff utility (mingw-get install msys-diffutils && diff
-U0 successfully-started.txt exits-immediately.txt). Your URL gives page
not found, and there's nothing under /notes/ or there's no such section in
the main URL.


> As far as the results from just bash vs bash with the "--login -i" ..
> they're slightly different, in that just bash gives me "exit" on the
> prompt,
> and with the args, it says "logout" Also, with the args, I get user@...
> and coloured prompt, whereas without I just get "bash-3.1$" as the prompt.
>

Ok so maybe it's not actually the exit command being sent via standard
input, more like it exits for some other crazy reason. It seems you have no
way to make bash work in cmd.exe, which makes me wonder if that's something
to do with your cmd.exe being a 64-bit application? Try to find someone
with 64-bit Windows and check if they can reproduce the problem.


> 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/
>

I think that's normal as described in bash docs.


> The files of the different runs (from the prompt that exits immediately and
> from mintty, where I typed exit manually) I put up are:
>
> The unique paths lists from each run
> LogBash2a_paths_uniq.txt
> LogBash2b-mintty_paths_uniq.txt
>
> The two full (unmodified) csv logs from each run:
> LogBash2a.CSV
> LogBash2b-mintty.CSV
>
> The two logs that I added in dummy lines to line them up (my stupid compare
> program forced me to put in the first few fields, but you can see all the
> times in inserted lines are identical, and they only have the first few
> fields anyway..):
> LogBash2a5.CSV
> LogBash2b-mintty_RE-AL8.CSV
>
> I don't know if that helps, (as it didn't seem to help me much, but maybe
> you or someone else can see something..? assuming you haven't given up on
> me
> yet..)  ;)
>

Well, where are those files at all? They're neither attached nor in your
linked website. Although if there isn't any difference in the files
accessed in both cases, then it's not a specific file causing the issue, I
would go for the 64-bit option mentioned above, i.e. try to reproduce the
problem in another 64-bit Windows.

On 03/11/12 18:22, Andrew wrote:
> From: Renato Silva [mailto:br.renatosilva@...]
> 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.

-- 
Regards,
Keith.

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.

2012/11/4 Keith Marshall <keithmarshall@...>

> 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

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.

2012/11/4 Keith Marshall <keithmarshall@...>

> 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.

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.

On Sat, Nov 3, 2012 at 9:00 PM, Renato Silva wrote:
>
> Ok so maybe it's not actually the exit command being sent via standard
> input, more like it exits for some other crazy reason. It seems you have no
> way to make bash work in cmd.exe, which makes me wonder if that's something
> to do with your cmd.exe being a 64-bit application? Try to find someone with
> 64-bit Windows and check if they can reproduce the problem.
>

I have already stated that I have no issue doing this on my Win64
64bit I7 laptop.

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.

-- 
Earnie
-- https://sites.google.com/site/earnieboyd

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.renatosilva@...]
>> 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

2012/11/5 Earnie Boyd <earnie@...>

> 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
> MinGW-users@...
>
> 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:mingw-users-request@...
>

On Mon, Nov 5, 2012 at 9:34 AM, Renato Silva wrote:
> 2012/11/5 Earnie Boyd <earnie@...>
>>
>> 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

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.

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

> -----Original Message-----
> From: Keith Marshall [mailto:keithmarshall@...]
> Sent: Sunday, November 04, 2012 1:39 AM
> 
> 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.

Yes, 64 bit Win7.

I have tried any way I could think of... which basically amounts to either
double-clicking the msys.bat file, (both as administrator and not) or
running it from a command prompt. My command prompt is run as administrator.

Since you said that, I noticed my default command prompt shortcut is in
windows\System32\cmd.exe - so I thought I'd try a shortcut to
windows\SysWOW64\cmd.exe since they're different, (which I guess makes
sense, but I didn't really think about it) and when run from System32, it
acts as I've described - msys.bat flashes another window briefly, too fast
to read, and that's it. Bash exits, and bash --login -i shows logout instead
of exit.

When I run SysWOW64\cmd.exe, msys.bat flashes another window, and then
promptly closes my command prompt window as well. That seems odd to me..
(but then, so did the behavior of the bashrc and bash_logout until you
enlightened me)

The 5 differences in the Environment are ProgramFiles and CommonProgramFiles
have the (x86) in them in the SysWOW64, the ComSpec's are set respectively,
and the SysWOW64 has an extra:

PROCESSOR_ARCHITEW6432=AMD64

... and the PROCESSOR_ARCHITECTURE for the System32 is AMD64, whereas for
the SysWOW64 it is set to x86 (seems backwards to me, but again, we've
demonstrated how much I know about these things)

Thank you for trying to help me. Much appreciated.

Andrew

From: Renato Silva [mailto:br.renatosilva@...] 
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

2012/11/5 Andrew <notes@...>

> From: Renato Silva [mailto:br.renatosilva@...]
> 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

On Mon, Nov 5, 2012 at 4:24 PM, Renato Silva wrote:
>
>
> 2012/11/5 Andrew <notes@...>
>>
>> From: Renato Silva [mailto:br.renatosilva@...]
>> 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

2012/11/4 Keith Marshall <keithmarshall@...>

>
> 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?

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

> -----Original Message-----
> From: Earnie Boyd [mailto:earnie@...]
> Sent: Monday, November 05, 2012 5:26 AM
> 
> 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.

Just for the record, to eliminate any possible environment pollution, I
created a batch file to set all of my environment variables to nothing,
except the PATH, PROMPT, and TMP (sh complained when I had no TMP set) and
tried running both bash and sh (despite them apparently being the same) with
and without --login -i and also just running the msys.bat - I also tried
these both in the SysWOW64 command prompt and the system32 command prompt,
both as Admin.

My path was set to simply e:\msys\1.0\bin;e:\MinGW\bin

bash runs my .bashrc file whereas sh doesn't, but only when bash is run
*without* --login -i

Running msys.bat closes the command prompt window in both SysWOW64 and
System32 command prompts.

Aside from that there is no difference than when running with all my
previous environment variables set.

Does that sufficiently clear up the possibility of this being and
environment issue, or should I try something else?

Thanks again,

Andrew

2012/11/21 Earnie Boyd <earnie@...>

> Are you not capable of searching the internet for the answers?


How about you, are you not capable of knowing what ';' does?

2012/11/21 Andrew <notes@...>

> Just for the record...
>

Hi Andrew, did you get any other 64-bit (or even 32-bit) WIndows
installation to reproduce the problem? Also, just random guessing, but is
cmd.exe (both 64 and 32) running in some compatibility mode (you can check
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. However, at this point
of time (I thought you just gave up or fixed it without feedback), I would
seriously consider *debugging* MSYS.

From: Renato Silva [mailto:br.renatosilva@...] 
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. :)

On Tue, Dec 4, 2012 at 6:18 PM, Andrew <notes@...> 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