mingw-msys Mailing List for MinGW - Minimalist GNU for Windows

Read and respond to this message at: 
https://sourceforge.net/forum/message.php?msg_id=3496721
By: jswalter

anyway to get the "package" of MSYS *without* the installer?

I'd just like to have the files, and some indication of what and where
the are/go.

I pray there are not reg keys used in this.

thx

walter


______________________________________________________________________
You are receiving this email because you elected to monitor this forum.
To stop monitoring this forum, login to SourceForge.net and visit: 
https://sourceforge.net/forum/unmonitor.php?forum_id=338575

Hi everyone,

I'm using MingW 4.1.0 with MSYS 1.0.11-2004-04-30-1.exe and
MSYSDTK-1.0.1.exe and I am experiencing strange behaviour when using
backticks to launch a program that returns the path of an executable to
stdout. What I am finding is that I am getting an extra hex character 0x01
introduced into the output stream, which causes the compile to fail when a
backticked xxx_config program is used to output a path which can be fed into
the command line for gcc.

Here is a self-contained example showing the problem. First compile the
included test.c program below using gcc:


#include <stdio.h>

main()
{
	printf("this is a test string\n");
}


$ gcc -o test test.c


The build scripts I am using as part of the package I am working with are
cross platform, and what they do is use backticks to capture the output from
various xxx_config executables and then append the link flags as required. A
simplified version of what is happening is given below:

$ echo "`./test` -lpq" &> pgconfig.out

If you try and view the resulting output using cat, then everything looks
fine on the surface, but then feeding the output into the compiler fails.
Looking closer using hexdump
(http://www.canb.auug.org.au/~millerp/hexdump.html), it appears that somehow
MingW/mSYS has inserted an extra 0x01 character at the end of the output
from the backticks, between the 0x67 and 0x20 bytes. It is this extra
character being fed to gcc which causes it not to find the path specified.

$ hexdump < pgconfig.out 
00000000: 74 68 69 73 20 69 73 20 61 20 74 65 73 74 20 73  this is a test s
00000010: 74 72 69 6E 67 01 20 2D 6C 70 71 0A              tring. -lpq.


This compares to a Linux box running FC4 which gives the following (and IMHO
correct) output:

$ hexdump < pgconfig.out
00000000  74 68 69 73 20 69 73 20  61 20 74 65 73 74 20 73  |this is a test
s|
00000010  74 72 69 6e 67 20 2d 6c  70 71 0a                 |tring -lpq.|
0000001b

Is there a way to remove the extra 0x01 character that mSYS is appending to
the backticked output, since it is causing several build scripts to fail? I
have tried searching the archives for backticks but couldn't find anything
related. Or is it that this is a known bug, and upgrading to one of the
later unstable releases will help solve this?


Many thanks,

Mark.

------------------------
WebBased Ltd
17 Research Way
Plymouth
PL6 8BT

T: +44 (0)1752 797131
F: +44 (0)1752 791023

http://www.webbased.co.uk   
http://www.infomapper.com
http://www.swtc.co.uk  

This email and any attachments are confidential to the intended recipient
and may also be privileged. If you are not the intended recipient please
delete it from your system and notify the sender. You should not copy it or
use it for any purpose nor disclose or distribute its contents to any other
person.

--- Mark Bourne <mc...@ec...>写道:

> The download and FAQ pages suggest that there is a
> single-file 
> distribution for MinGW, but looking at the download
> page I can't work 
> out which file this is. Which one is it? I assume
> it's one of the many 
> files in the "Current" section?
> 
> Also, what do I need for MSYS? Do I just need
> MSYS-1.0.10.exe, or do I 
> also need some files from the "MSYS Developer Tool
> Kit"?
> 
> I want to be able to compile and run programs, use
> makefiles etc. If 
> it's any help in offering advice, I am trying to
> compile programs that 
> use libusb-win32
> (http://libusb-win32.sourceforge.net/) - they seem
> to 
> suggest using MinGW and MSYS. I've tried a gcc from
> another place 
> (DJGPP), but haven't been able to make it work with
> libusb-win32, so 
> thought I'd try MinGW since that's what their
> instructions use. The only 
> problem is what to download for MinGW/MSYS?
> 

you can download full runtime mingw from:
http://sourceforge.net/projects/mingw-install


> Thanks,
> Mark.
> 
> 
> 
>
-------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do
> you grep through log files
> for problems?  Stop!  Download the new AJAX search
> engine that makes
> searching your log files as easy as surfing the 
> web.  DOWNLOAD SPLUNK!
>
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
> _______________________________________________
> Mingw-msys mailing list
> Min...@li...
>
https://lists.sourceforge.net/lists/listinfo/mingw-msys
> 


__________________________________________________
赶快注册雅虎超大容量免费邮箱?
http://cn.mail.yahoo.com

The download and FAQ pages suggest that there is a single-file 
distribution for MinGW, but looking at the download page I can't work 
out which file this is. Which one is it? I assume it's one of the many 
files in the "Current" section?

Also, what do I need for MSYS? Do I just need MSYS-1.0.10.exe, or do I 
also need some files from the "MSYS Developer Tool Kit"?

I want to be able to compile and run programs, use makefiles etc. If 
it's any help in offering advice, I am trying to compile programs that 
use libusb-win32 (http://libusb-win32.sourceforge.net/) - they seem to 
suggest using MinGW and MSYS. I've tried a gcc from another place 
(DJGPP), but haven't been able to make it work with libusb-win32, so 
thought I'd try MinGW since that's what their instructions use. The only 
problem is what to download for MinGW/MSYS?

Thanks,
Mark.

On Friday 23 December 2005 9:15 am, you wrote:
> Hello!
>
> >>If your directory structure changes, the only modifications you would
> >>need to
> >>make would be to the /etc/fstab file and you would need to create a
> >> desktop icon if you wish to have it click start from your desktop.
> >
> > Thanks, I'll try (...and occupy the laptop of my girlfriend ;-)).
>
> Some feedback: Copying the installation dirctories to CD and then back
> to Windows using a
> different partition and OS did work well, besides:
>
> PORT packages manually compiled and installed install *.la files. These
> contain paths relative to the initial installation and thus have to be
> adapted to the new directory names. Not realy a problem to MINGW/MSYS
> but worth to mention.

This would apply to *any* application which depends on compiled in PATH 
settings -- not just to mingwPORTs.  If you simply copy the application files 
to a different machine, with a different filesystem layout, you will break 
such dependencies.  This is the main reason why you are advised to avoid
overriding default installation paths.

Regards,
Keith.

Quoting Tim Teulings <ra...@ed...>:

> Hello!
>
>>> If your directory structure changes, the only modifications you would
>>> need to
>>> make would be to the /etc/fstab file and you would need to create a desktop
>>> icon if you wish to have it click start from your desktop.
>>
>>
>> Thanks, I'll try (...and occupy the laptop of my girlfriend ;-)).
>
> Some feedback: Copying the installation dirctories to CD and then back
> to Windows using a
> different partition and OS did work well, besides:
>
> PORT packages manually compiled and installed install *.la files. These
> contain paths relative to the initial installation and thus have to be
> adapted to the new directory names. Not realy a problem to MINGW/MSYS
> but worth to mention.
>

Another reason to rebuild the PORT packages is that the mingwPORT scripts add
the -march value to the compile for maximum performance.  If the architecture
were different you would need to rebuild even if the directory structure
remained the same.


Kind Regards,
Earnie Boyd

For all your online shopping needs http://shop.siebunlimited.com.  Register an
account online and receive a 25% discount on your first purchase.

Hello!

>>If your directory structure changes, the only modifications you would
>>need to
>>make would be to the /etc/fstab file and you would need to create a desktop
>>icon if you wish to have it click start from your desktop.
> 
> 
> Thanks, I'll try (...and occupy the laptop of my girlfriend ;-)).

Some feedback: Copying the installation dirctories to CD and then back
to Windows using a
different partition and OS did work well, besides:

PORT packages manually compiled and installed install *.la files. These
contain paths relative to the initial installation and thus have to be
adapted to the new directory names. Not realy a problem to MINGW/MSYS
but worth to mention.

-- 
Gruß...
       Tim.

Read and respond to this message at: 
https://sourceforge.net/forum/message.php?msg_id=3487579
By: s_jubeh

I am trying to build mapserver i have built it with microsft compiler but some
option not supported there i have installed msys/mingu now i want to compile
mapserver using this tool.


where i have to put the source that i want to compile and where i have to put
the precompiled library that the source need it.




______________________________________________________________________
You are receiving this email because you elected to monitor this forum.
To stop monitoring this forum, login to SourceForge.net and visit: 
https://sourceforge.net/forum/unmonitor.php?forum_id=338575

Read and respond to this message at: 
https://sourceforge.net/forum/message.php?msg_id=3487163
By: keithmarshall

Can you build and run a simple `Hello World' program, as described here:
http://mingw.org/docs.shtml#compilingandbuilding

Without details of the error messages from your failed project build, there
isn't much advice to be offered -- you don't even say which library can't be
found.

Does your configure script even support --with-lib, in the form you've tried.
What does `configure --help' say for that option?

Sorry, but without a more detailed description of the problem, we can't be more
helpful.

Regards,
Keith.

______________________________________________________________________
You are receiving this email because you elected to monitor this forum.
To stop monitoring this forum, login to SourceForge.net and visit: 
https://sourceforge.net/forum/unmonitor.php?forum_id=338575

Read and respond to this message at: 
https://sourceforge.net/forum/message.php?msg_id=3487116
By: s_jubeh

I have installed the mingu and msys on my pc "winxp" i am trying now to compile
a source code. i have configuration file "./configure"

when i run it it give me a message error cannot fing a library

so i have used ./configure --with-lib=LIBPATH
Also it did not work . i want to know what are the paths that the compiler check
it. and where i have to put the source code and where i have to put the built
libraries and binaries.do i have to creat a folder C:\msys\home\%myfolder%

Thanx in advance

______________________________________________________________________
You are receiving this email because you elected to monitor this forum.
To stop monitoring this forum, login to SourceForge.net and visit: 
https://sourceforge.net/forum/unmonitor.php?forum_id=338575

The webcam was off, and not even plugged into the USB port, and 
ostensibly I had no webcam-associated software running at the time. When 
I do plug it in and open the Logitech application to see video, it shows 
up in "My Computer" without a drive letter associated with it. There was 
a Logitech tiny icon in the special section of the program bar where you 
see internet connection, volume, etc., and I removed that, though it 
seemed to be just a shortcut to the main webcam program.

I found the LVPrcSrv.exe file in C:\Program Files\Common 
Files\Logitech\LVMVFM. I changed the name to bad_LVPrcSrv.off. I have 
yet to figure out what if anything I'm missing without this offending 
program. A Google search for LVPrcSrv.exe turned up hints that the 
program causes problems.

Bruce Sherwood

Earnie Boyd wrote:

> Quoting Bruce Sherwood <Bru...@nc...>:
>
>> Thanks to those who offered suggestions about my problems working in 
>> the MSYS environment.
>>
>> I found the problem. It was LVPrcSrv.exe, a component of software I'd 
>> installed that came with a Logitech webcam. I hadn't suspected this 
>> software installation because I had no problems using MSYS for a week 
>> or more before the trouble hit. Yuck!
>>
>
> I'm wondering if perhaps you had the webcam off or on with the 
> problems?  Does
> the webcam share the same USB port with some external device used for 
> storage? Does the webcam cause a device letter to be used?
>
> Kind Regards,
> Earnie Boyd
>
> For all your online shopping needs http://shop.siebunlimited.com.  
> Register an
> account online and receive a 25% discount on your first purchase.
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log 
> files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
> _______________________________________________
> Mingw-msys mailing list
> Min...@li...
> https://lists.sourceforge.net/lists/listinfo/mingw-msys

Quoting Bruce Sherwood <Bru...@nc...>:

> Thanks to those who offered suggestions about my problems working in 
> the MSYS environment.
>
> I found the problem. It was LVPrcSrv.exe, a component of software I'd 
> installed that came with a Logitech webcam. I hadn't suspected this 
> software installation because I had no problems using MSYS for a week 
> or more before the trouble hit. Yuck!
>

I'm wondering if perhaps you had the webcam off or on with the problems?  Does
the webcam share the same USB port with some external device used for 
storage? Does the webcam cause a device letter to be used?

Kind Regards,
Earnie Boyd

For all your online shopping needs http://shop.siebunlimited.com.  Register an
account online and receive a 25% discount on your first purchase.

Thanks to those who offered suggestions about my problems working in the 
MSYS environment.

I found the problem. It was LVPrcSrv.exe, a component of software I'd 
installed that came with a Logitech webcam. I hadn't suspected this 
software installation because I had no problems using MSYS for a week or 
more before the trouble hit. Yuck!

Bruce Sherwood

Greg Chicares wrote:

>On 2005-12-20 3:59 UTC, Bruce Sherwood wrote:
>  
>
>>I'm new to this list but have used MSYS/MinGW on Windows XP for some
>>time to create Windows binaries for VPython (an easy-to-use 3D
>>programming environment; see vpython.org). About two days ago MSYS
>>stopped working properly
>>    
>>
>
>MinGW and MSYS don't depend on any registry entries, so that can
>be ruled out right away.
>
>Have you changed your PATH? Even if you changed it 'only' for
>windows, MSYS inherits that.
>
>Have you recently installed other, similar software like cygwin?
>
>Have you changed the MSYS mount table, or moved MSYS or MinGW
>files to a different directory than they formerly resided in?
>
>Have you installed an updated version of MinGW or MSYS?
>
>Probably you've already thought of those things, of course.
>
>You might try launching MSYS without rxvt. I think the
>recommended way to do that is to rename 'rxvt.exe' in the
>msys/1.0/bin/ directory. Just change its name to anything else.
>
>  
>
>>I have of course tried reinstalling, tried different
>>versions, tried it on a colleague's machine, all to no avail.
>>    
>>
>
>I find it especially interesting that you have the same problems
>on another machine. This seems to rule out flaky hardware.
>
>Is this machine in a corporation? Sometimes they change things
>for all users at the same time, and sometimes the people doing
>an 'upgrade' don't know the ramifications. Have you tried
>installing these tools on your home computer?
>
>  
>
>>The main symptom is that when I try to run a script such as a make or
>>configure or bjam (to build boost libraries), the process hangs on some
>>statement.
>>    
>>
>
>That rules out 'make', because jam is independent.
>
>  
>
>>For example, if it drives gcc I see the file produced but the
>>process doesn't advance to the next statement, as though gcc doesn't
>>exit properly or the script doesn't detect the existence of the produced
>>file. My colleague even suggested that maybe an automatic Norton
>>antivirus update might have screwed up something about the file system,
>>so I turned it off to no avail.
>>    
>>
>
>When it 'hangs', what does the msw 'task manager' tell you?
>Do the script and the compiler processes terminate? If not, do
>they continue to consume CPU or I/O resources?
>
>Are other low-level processes running in the background, which
>might change files surreptitiously--a badly-behaved defragmenter,
>perhaps?
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
>for problems?  Stop!  Download the new AJAX search engine that makes
>searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
>http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
>_______________________________________________
>Mingw-msys mailing list
>Min...@li...
>https://lists.sourceforge.net/lists/listinfo/mingw-msys
>  
>

Greg Chicares wrote, quoting Bruce Sherwood:
>> I'm new to this list but have used MSYS/MinGW on Windows XP for some
>> time to create Windows binaries for VPython (an easy-to-use 3D
>> programming environment; see vpython.org). About two days ago MSYS
>> stopped working properly

[snip]

> You might try launching MSYS without rxvt. I think the
> recommended way to do that is to rename 'rxvt.exe' in the
> msys/1.0/bin/ directory. Just change its name to anything else.

This would be my guess, too.  As a GNU Troff (groff) developer, I
routinely rebuild groff CVS snapshots under MSYS.  At some point
during the 1.19.1 development cycle, the build process started to
hang, when invoked from a shell running in rxvt, but the problem
disappeared when rxvt was removed from the equation.

I can still reproduce this failure today, and at least one other
user recently reported an identical problem, and solution:
http://sourceforge.net/mailarchive/message.php?msg_id=13797758

As Greg suggests, rename rxvt.exe to (say) rxvt.off, or, if you are
using msys-1.0.11, add the -norxvt switch to the msys.bat startup
shortcut, and try again.

Regards,
Keith.

On 2005-12-20 3:59 UTC, Bruce Sherwood wrote:
> I'm new to this list but have used MSYS/MinGW on Windows XP for some
> time to create Windows binaries for VPython (an easy-to-use 3D
> programming environment; see vpython.org). About two days ago MSYS
> stopped working properly

MinGW and MSYS don't depend on any registry entries, so that can
be ruled out right away.

Have you changed your PATH? Even if you changed it 'only' for
windows, MSYS inherits that.

Have you recently installed other, similar software like cygwin?

Have you changed the MSYS mount table, or moved MSYS or MinGW
files to a different directory than they formerly resided in?

Have you installed an updated version of MinGW or MSYS?

Probably you've already thought of those things, of course.

You might try launching MSYS without rxvt. I think the
recommended way to do that is to rename 'rxvt.exe' in the
msys/1.0/bin/ directory. Just change its name to anything else.

> I have of course tried reinstalling, tried different
> versions, tried it on a colleague's machine, all to no avail.

I find it especially interesting that you have the same problems
on another machine. This seems to rule out flaky hardware.

Is this machine in a corporation? Sometimes they change things
for all users at the same time, and sometimes the people doing
an 'upgrade' don't know the ramifications. Have you tried
installing these tools on your home computer?

> The main symptom is that when I try to run a script such as a make or
> configure or bjam (to build boost libraries), the process hangs on some
> statement.

That rules out 'make', because jam is independent.

> For example, if it drives gcc I see the file produced but the
> process doesn't advance to the next statement, as though gcc doesn't
> exit properly or the script doesn't detect the existence of the produced
> file. My colleague even suggested that maybe an automatic Norton
> antivirus update might have screwed up something about the file system,
> so I turned it off to no avail.

When it 'hangs', what does the msw 'task manager' tell you?
Do the script and the compiler processes terminate? If not, do
they continue to consume CPU or I/O resources?

Are other low-level processes running in the background, which
might change files surreptitiously--a badly-behaved defragmenter,
perhaps?

I'm new to this list but have used MSYS/MinGW on Windows XP for some 
time to create Windows binaries for VPython (an easy-to-use 3D 
programming environment; see vpython.org). About two days ago MSYS 
stopped working properly, and I'm at my wits end trying to get it to 
work again. I have of course tried reinstalling, tried different 
versions, tried it on a colleague's machine, all to no avail. I'm hoping 
that my symptoms are familiar to someone.

The main symptom is that when I try to run a script such as a make or 
configure or bjam (to build boost libraries), the process hangs on some 
statement. For example, if it drives gcc I see the file produced but the 
process doesn't advance to the next statement, as though gcc doesn't 
exit properly or the script doesn't detect the existence of the produced 
file. My colleague even suggested that maybe an automatic Norton 
antivirus update might have screwed up something about the file system, 
so I turned it off to no avail.

In addition to this symptom, I'm also seeing nonreproducibility. 
Sometimes a configure script runs fine and sometimes the same script fails.

Sorry that I can't give a simple test, but maybe someone can suggest 
one. I'm a reasonably competent programmer but not expert in 
autoconfigured configure scripts, which I've inherited.

Bruce Sherwood

Read and respond to this message at: 
https://sourceforge.net/forum/message.php?msg_id=3483149
By: keithmarshall

Yes!!!  RTFM -- the one distributed with MSYS in the form of README files.

With current releases of MSYS, you MUST NOT put your own binaries in MSYS' /bin
or /usr/bin -- these directories are reserved for specially built binaries,
which are part of MSYS itself, (they are compiled using a custom compiler
environment, and linked against msys-1.0.dll).

Your own binaries can go anywhere else -- I keep mine in /usr/local/bin, but
/mingw/bin is equally good.

Regards,
Keith.

______________________________________________________________________
You are receiving this email because you elected to monitor this forum.
To stop monitoring this forum, login to SourceForge.net and visit: 
https://sourceforge.net/forum/unmonitor.php?forum_id=338575

Read and respond to this message at: 
https://sourceforge.net/forum/message.php?msg_id=3483095
By: mike0

After I move arg.exe from C:\msys\1.0\bin to c:\mingw\bin, everything just works
fine !!!

replay the test
$ ./test.sh
argc=3
argv[0]=c:\MingW\bin\arg.exe
argv[1]=-v
argv[2]=-c

Is there anybody can tell me why?

______________________________________________________________________
You are receiving this email because you elected to monitor this forum.
To stop monitoring this forum, login to SourceForge.net and visit: 
https://sourceforge.net/forum/unmonitor.php?forum_id=338575

Christian Gudrian wrote:
> I have just downloaded the most recent version of MingW and MSYS.
> Now I have the problem, that MSYS obviously does not pass on command
> line options to the called progam.
>
> Example using MSYS:
>
> Gudrian@DEMETER ~
> $ gcc --version
> gcc.exe: no input files
>
> The --version parameter is not passed on to gcc.

IIRC, this happens when you ignore the installation instructions,
and install MSYS and MinGW into the same tree -- you MUST NOT put
MinGW binaries into the MSYS /bin directory.

> When I use CMD.EXE, everything works as expected:
>
> C:\msys\bin>gcc --version
> gcc (GCC) 3.4.2 (mingw-special)
> Copyright (C) 2004 Free Software Foundation, Inc.

And this tends to confirm that you have installed incorrectly.

You should remove your entire C:/msys directory tree, and reinstall
correctly.  The default installation paths are `C:/MSYS/1.0' for MSYS,
and `C:/MinGW' for MinGW.  I recommend that you stick with these
recommended defaults -- you may change the drive designator, if that
suits you better, but it's best to keep the same paths otherwise.

After installation, /etc/fstab in your MSYS tree should have the
mount specification `C:/MinGW<tab>/mingw' -- (N.B <tab> is the single
ASCII TAB character).

HTH.
Keith.

Hello!

Brandon J. Van Every wrote:

> Is this particular GCC the only GCC on your system? 

I do have a Cygwin version of gcc as well.  If I call that from an
MSYS shell, everything works:

Gudrian@DEMETER /c/cygwin/bin
$ ./gcc --version
gcc (GCC) 3.4.4 (cygming special) (gdc 0.12, using dmd 0.125)
Copyright (C) 2004 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There
is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.

Christian

Christian Gudrian wrote:

>Gudrian@DEMETER ~
>$ gcc --version
>gcc.exe: no input files
>  
>
Is this particular GCC the only GCC on your system?  Do you have a 
Cygwin GCC floating around somewhere, in your path?


Cheers,
Brandon Van Every
I won't spend more than 1 day configuring 1 thing.

Hello!

I have just downloaded the most recent version of MingW and MSYS.  Now
I have the problem, that MSYS obviously does not pass on command line
options to the called progam.

Example using MSYS:

Gudrian@DEMETER ~
$ gcc --version
gcc.exe: no input files

The --version parameter is not passed on to gcc.


When I use CMD.EXE, everything works as expected:

C:\msys\bin>gcc --version
gcc (GCC) 3.4.2 (mingw-special)
Copyright (C) 2004 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There
is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.

So it should be an issue with MSYS.

Any hints what might cause this strange behaviour?

I am using Windows XP SP2, BTW.

Thanks in advance,

Christian

Rich Simoes wrote, quoting me:
>> Well the advantage of option 4 is that it provides one standard script 
for 
>> invoking MSYS, whereas option 2 requires some other, user supplied 
wrapper 
>> script with a non-standard name.
>
> Agreed.
>
>> On the contrary, with option 4 I think:  "I want to start MSYS, so I 
need to
>> invoke msys.bat, but I don't like some of the default options, so I 
need to
>> customise some configuration file, which may be a user supplied 
auxiliary
>> script, which msys.bat will use to establish such customisations as I
>> require".  To me, that seems a more logical, and linear scenario.
>
> One problem, two solutions. And there could be more solutions.

Not really.  The option 2 approach relies on a wrapper script, which is 
not
a part of MSYS; it isn't inherently an MSYS solution, but it will *always*
remain an available option, for those who wish to exploit it.

OTOH, the option 4 approach provides a solution which is integral to MSYS
itself.  It defines a configuration mechanism which inherently relates to
MSYS exclusively.  In essence, it provides a method of local customisation
which is analogous to hacking msys.bat directly, but it does it in a 
manner
which MSYS recognises to be under the exclusive control of the end user;
therefore, it avoids any risk that MSYS itself would ever destroy the 
local
user's preferences.

>> Well, I can neither condone nor recommend arbitrary hacking within 
msys.bat. 
>> I can't forbid you to do it, but you have only yourself to blame if you 

>> subsequently destroy your configuration during a future upgrade or 
reinstall.
>
> arbitrary??? - Ouch! By hard coding the command line options
> on the rxvt line, I can not change them in any other way
> unless I edit them in the "msys.bat" file.

Yes, arbitrary!  You are making uncontrolled changes to a core system 
file,
in a manner which is entirely beyond the purview of the package 
maintainer.
Since your changes are never fed back into CVS, they are necessarily
volatile, and will not survive an in-place upgrade or reinstallation.

I do agree, however, that those hard coded options, on the rxvt start up
command, need to be represented in a manner which will support external
configuration.  Thanks for pointing this out.

>> OTOH, you *are* expected to configure /etc/fstab;  this is how you tell 
MSYS 
>> how *you* prefer to view your Windows filesystem in the pseudo-POSIX 
>> filesystem space which MSYS provides, and the installer can't make 
those 
>> choices.  This is entirely consistent with the manner in which 
filesystem 
>> mount points are configured in a real POSIX system, and IIRC, this 
>> configuration will *not* be overwritten during a subsequent MSYS 
upgrade or 
>> reinstallation.

I neglected to mention that /etc/fstab is provided entirely for the end 
user's
convenience; you can run a basic MSYS installation without ever looking at 
it,
or indeed, without it even existing in the first place.

> Well, if the user can put the "custom.bat" file along side
> the "msys.bat" file, without a new MSYS deleting it, then
> you might have something there. At least you should know
> where to look for it if you have a conditional test within
> "msys.bat".

This is exactly what I have in mind.

[concerning the use of environment variables to specify configuration]
>> I don't like this approach either.  Since *all* normal Win32 
environment 
>> variables are unconditionally exported, I have no way to set local 
>> definitions in msys.bat, in a manner which will be portable to all 
Win32 
>> variants, without needlessly and unnecessarily polluting the MSYS shell 

>> environment;  IMHO, there's already way too much junk in there already,
>> from the standard Windows set up.
>
> That's why I have extra code in my $HOME/.profile.
> It's the only way to get rid of all that junk
> once it is set in Windows.

Earnie seems to favour just the use of environment variables, to provide
user configuration hooks.  With all due respect to him, for without his
effort we would not have MSYS in the first place, I don't like the idea
of making such hooks a permanent feature of the Windows master 
environment,
particularly when they relate to only one specific application.  I accept
that environment variables may be necessary to provide the `glue' between
a user configuration file/script and the actual application, but I would
prefer to localise those application specific variables within the process
which launches the application; I just wish that Windows had provided a
suitable mechanism for me to select those which I want to export to
child processes.

Maybe the distributed /etc/profile should include unset commands, to clean
up the environment mess resulting for the export of variables which should
be needed only within the start up context.  Any thoughts?

[concerning the use of separate configuration files vs. msys.bat hacking]
>> Well, this is the way I would prefer to see things done; if you are too 
lazy 
>> to adopt such a configuration strategy, then again, you have only 
yourself to 
>> blame if you come unstuck, as a result.
>
> lazy??? - Double ouch! It happens to be my personal
> preference [to hack e.g. msys.bat] when presented with multiple options.
>
> The lack of true User Data area for most of
> the life of Windows has made user customizations
> difficult. I actually prefer not to customize
> anything within an installed application tree.
> For my needs, I see no option available to get
> around modifying "fstab" and "msys.bat".

If you don't want to customise, then you should be happy to work with the
system defaults.  As noted above, /etc/fstab is provided specifically to
support user customisation -- part of which is to specify *your* choice
of installation directory for MinGW, if you use it.  OTOH, you really
should *not* be customising msys.bat to suit your own preferences; that
function properly belongs in some other configuration file, which is
specifically intended for user customisation.  I accept that msys.bat
may need some modifications, which should be standardised within the
distributed package, to make it more amenable to such customisation.
It really shouldn't be any more difficult for you to edit a file which
is specifically provided for that purpose, than it is to hack a file
which you aren't supposed to modify.  When you find that you need to
do this, that indicates a flaw in the core system.  Ok, the accusation
of laziness may be unwarranted, sorry, but you could have submitted a
bug report, or better still, a patch.

Regards,
Keith.

Just before the start of rxvt

if "x%RXVTRC%" == "x" set RXVTRC="-backspacekey ^H -sl 2500 -fg %FGCOLOR% -bg
%BGCOLOR% -sr -fn Courier-12 -tn msys -geometry 80x25"

Then change the start line to:

start %WD%bin\rxvt %RXVTRC% -e /bin/sh --login -i



This provides the user hook needed.  Note, I have not tested it.

Earnie

Brandon J. Van Every wrote:
> R M S wrote:
>
>> How can a script be passed from one user to another
>> and know where to find "msys.bat" on each user's
>> machine?
> 
> 
> Because it's part of a path, which in turn is part of someone's standard 
> build system.  This is about software engineering and reliable, 
> reproducible builds.  Not hacking.  If you don't have this perspective, 
> then there is little point in debating further.

Certainly. I just wanted to hear what you
had to say on the topic.

Rich Simoes