[ANNOUNCEMENT] mintty-0.5.8-1
Mintty is a terminal emulator for Cygwin with a native Windows user
interface and minimalist design. Among its features are Unicode
support and a graphical options dialog. Its terminal emulation is
largely compatible with xterm, but it does not require an X server.
Mintty is based on code from PuTTY by Simon Tatham and team.
CHANGES
===
This release fixes a single issue: font names with non-ASCII
characters weren't read correctly from the config file, thus causing
settings such as ＭＳ ゴシック (MS Gothic) to be ignored.
QUESTIONS
=
The mintty manual is installed as a manpage ('man mintty'), and it's
also available in PDF format at
http://mintty.googlecode.com/files/mintty-0.5.8.pdf. Questions and
comments can be sent to the mintty discussion group at
http://groups.google.com/group/mintty-discuss or the Cygwin mailing
list at cyg...@cygwin.com. Please use the issue tracker at
http://code.google.com/p/mintty/issues/list to report bugs or suggest
enhancements.
To update your installation, click on the "Install Cygwin now" link
on the http://cygwin.com/ web page. This downloads setup.exe to
your system. Then, run setup and answer all of the questions.
*** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***
If you want to unsubscribe from the cygwin-announce mailing list, look
at the "List-Unsubscribe: " tag in the email header of this message.
Send email to the address specified there. It will be in the format:
cygwin-announce-unsubscribe-you=yourdomain@cygwin.com
If you need more information on unsubscribing, start reading here:
http://sourceware.org/lists.html#unsubscribe-simple
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem in calling _stat() on Cygwin 1.7
Hello all,
I was testing a program written by someone else that calls _stat() (note the
leading underscore). However it was not giving an expected result. Consider
this sample program.
FILE statex.c:
#include
#include
int
main (void)
{
struct stat s;
assert (_stat ("/bin/ls", &s) == 0);
int exe_bits = (s.st_mode & S_IXUSR) &&
(s.st_mode & S_IXGRP) &&
(s.st_mode & S_IXOTH);
assert (exe_bits);
return 0;
}
Then I typed this command:
$ gcc -o statex statex.c
$ ls -l /bin/ls
-rwxr-xr-x 1 testusr Administrators 129536 2008-12-18 06:16 /bin/ls
$ ./statex
assertion "exe_bits" failed: file "statex.c", line 15, function: main
Aborted (core dumped)
-
I debugged with gdb and concluded that the _stat() was not filling the stat
structure correctly. However, if I called stat() instead of _stat(), then there
was no problem - no assertion failure, structure was filled correctly.
I suspected maybe I should not use struct stat, so I tried other variations,
such as stat32, stat64, _stat32, _stat64, ... However only struct stat led to
correct compilation (and gave wrong result).
Is it a problem with _stat(), or did I make a mistake in the 2nd argument in
calling _stat()?
Thanks for help.
Dave Lee.
cygcheck.out
Description: Binary data
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Problem in calling _stat() on Cygwin 1.7
Am 27.02.2010, 12:57 Uhr, schrieb Dave Lee : Is it a problem with _stat(), or did I make a mistake in the 2nd argument in calling _stat()? If it (meddling with internal affairs, such as using _stat) hurts too much, then don't do it (use stat instead, it's standardized). -- Matthias Andree -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Problem in calling _stat() on Cygwin 1.7
> If it (meddling with internal affairs, such as using _stat) > hurts too much, then don't do it (use stat instead, it's > standardized). An off-topic question: on system where both XXX() and _XXX() are available (where XXX = open, read, write, access, chmod, ... etc), can one assume what _XXX() does, and that _XXX() behaves the same as XXX()? Thanks for help. Dave Lee -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: R: bash hang question
I was running cygwin-1.7 snapshots 20100223. I tried out 20100226 and got the same issue under cygwin console and mintty. Bash hang under "ESC 24;" sequence. Some of the cygwin package information is as follows: Cygwin DLL version info: DLL version: 1.7.2 Build date: Fri Feb 26 16:41:49 EST 2010 bash3.2.49-23 bash-completion 1.1-2 libreadline54.3-5 libreadline65.2.14-12 libreadline76.0.3-2 mintty 0.5.8-1 It could just me having this issue. Thanks. Regards, Eric. - Original Message - From: Marco Atzeri Date: Friday, February 26, 2010 11:19 pm Subject: R: bash hang question To: cygwin@cygwin.com, ERIC HO > --- Sab 27/2/10, ERIC HO ha scritto: > > > I reported a bash hang issue a few > > months ago. When in bash, after enter ESC 2 4 > > the prompt looks like this: > > (arg: 24) > > Pressing ';' at this point causes bash to hang. > > > on my cygwin-1.7 snapshots 20100224, I have no hang, > the output is: > > $ > > my bash and readline are the last ones. > > > Someone indicated it is a missed degenerate case in > > Readline. > > I contacted the GNU Readline maintainer who said he could > > not duplicate the problem. But he does not use cygwin. Not > > sure whether this is cygwin > > specific or not. > > Thanks. > > > > -- > > Problem reports: http://cygwin.com/problems.html > > could you follow this ? Eventually we could have some hint. > > Regards > Marco > > > > > > -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
xerces-c-3.0.1 linking problem
Hi, My application uses the xerces-c-3.0.1 library. When linking to the library (with libtool), I am getting the following error message: /bin/sh ../../libtool --tag=CXX --mode=link g++ -O3 -s -g -O2 -Wl,--enable-auto-import -o libmylib.la mycode.lo -lxerces-c /usr/bin/grep: /usr/lib/gcc/i686-pc-cygwin/4.3.2/libstdc++.la: No such file or directory /usr/bin/sed: can't read /usr/lib/gcc/i686-pc-cygwin/4.3.2/libstdc++.la: No such file or directory libtool: link: `/usr/lib/gcc/i686-pc-cygwin/4.3.2/libstdc++.la' is not a valid libtool archive Note the version of libstdc++ the above is trying to find: 4.3.2 The current version in cywgin is 4.3.4. It looks to me that the libxerces-c-3.0.1 libraries were created with an older version of the compiler and are not up to date any more. Is this a bug? Or am I missing something? Regards, Johan -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: xerces-c-3.0.1 linking problem
Johan De Taeye wrote: > Note the version of libstdc++ the above is trying to find: 4.3.2 > The current version in cywgin is 4.3.4. > > It looks to me that the libxerces-c-3.0.1 libraries were created with > an older version of the compiler and are not up to date any more. > Is this a bug? Or am I missing something? Nope, you're correct. C++ libraries must all be compiled with compatible versions of the same compiler. Now, it's possible that 4.3.2 and 4.3.4 are compatible, but the libtool .la file records the EXACT version number. One possible work around -- which may work, but might not -- is to simply delete the xerces .la files and try to build your app again. I'll release an updated xerces package in due course, but there are other things higher on the TODO list... -- Chuck -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Problem in calling _stat() on Cygwin 1.7
On 27/02/2010 15:14, Dave Lee wrote: >> If it (meddling with internal affairs, such as using _stat) hurts too >> much, then don't do it (use stat instead, it's standardized). > > An off-topic question: on system where both XXX() and _XXX() are available > (where XXX = open, read, write, access, chmod, ... etc), can one assume > what _XXX() does, and that _XXX() behaves the same as XXX()? Not in general, no. Anything beginning with an underscore is, as a general rule, private and internal to the library or toolchain. Or, as is probably the case in the code this originally came from, it's a reference to the MSVC version of the function; MSVCRT contains a lot of the POSIX functions, but they're all not-quite fully compatible, so they are prefixed with an '_' to distinguish them. These functions are also available using MinGW, but you don't want to use them on Cygwin; remove the underscore and use the native POSIX version. However, the real problem in this case is that there is a prototype for stat(), but none for _stat(), in the include headers: > $ gcc -o statex statex.c --save-temps -g3 -gstabs+ -W -Wall > statex.c: In function 'main': > statex.c:9: warning: implicit declaration of function '_stat' > > $ Somehow, this bypasses some kind of hidden internal magic that (?i think?) substitutes the 64-bit version of stat for the regular one, and things go downhill from there. Moral of the story: *always* compile with warnings enabled, even for trivial test programs! cheers, DaveK -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: xerces-c-3.0.1 linking problem
On 27/02/2010 17:03, Charles Wilson wrote: > Johan De Taeye wrote: > >> Note the version of libstdc++ the above is trying to find: 4.3.2 >> The current version in cywgin is 4.3.4. >> >> It looks to me that the libxerces-c-3.0.1 libraries were created with >> an older version of the compiler and are not up to date any more. >> Is this a bug? Or am I missing something? > > Nope, you're correct. C++ libraries must all be compiled with compatible > versions of the same compiler. Now, it's possible that 4.3.2 and 4.3.4 > are compatible, It is guaranteed. > but the libtool .la file records the EXACT version number. > > One possible work around -- which may work, but might not -- is to > simply delete the xerces .la files and try to build your app again. There's a helper script in the gcc4 package to update all the installed .la files it can find in /usr/lib: take a look at /usr/sbin/fix-libtool-scripts-for-latest-gcc-runtimes.sh Try giving it a go. (NB: may be missing 'x' perms on your system owing to packaging bug in 4.3.4-3; chmod or source it as you prefer.) cheers, DaveK -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin's svn appends unwanted .exe to file name on checkout
On 26/02/2010 22:45, David Rothenberger wrote: > I know the Cygwin DLL has some "magic" for appending the .exe extension > and I suspect that's getting in the way here, but I don't know when or > why it happens. I believe it happens a lot more if you go using DOS paths(*). Do not do that. cheers, DaveK -- (*) - WAG: Cygwin automagically adds 'x' perms to files you access via dos drive-letters, so the files in the repo get 'x', and when the client checks them back out again and creates new files (this time with real rather than automagically-added-on-access 'x' perms), the .exe magic kicks in. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: ssh + patch + $TMP
Cyrille Lefevre laposte.net> writes:
... deleted ...
>
> may be you may post your code ?
>
> Regards,
>
> Cyrille Lefevre
Cyrille,
the script is appended in uuencoded form
(due to some lines longer 80 characters).
regards
kf
=
begin 755 000-ssh-session-env.sh
M(r...@+v)I;B]B87-H"B,*(R`P,#`P,#`P+7-S:"US97-S:6]N+65N=BYS:"`M
M('-CF5R
M;V5S"B,*(R!B96-A=7-E(&EN('-E'!A;F1I;F<@=VEN9&]W
MU1(25-30U))4%0E+BI]+FYA;65L:7-T+B0D+G-H"B`@
M0D%40TA30U))4%0])'M42$E34T-225!4)2XJ?2YN86UE;&ES="XD)"YB870*
M"b...@8vqe86yu<%]E>&ET*"D*("!["B`@("!R;2`M9B`D5$U01$E2+R133U52
M0T530U))4%0@)%1-4$1)4B\D0D%40TA30U))4%0@,CXO9&5V+VYU;&P*("`@
M('5M87-K("1S879E7U5-05-+"B`@("!U;G-E="!33U520T530U))4%0*("`@
M('5N"1)3D9/4$%42"(@(3T@(g...@b(%T@)B8@"154T52(B`A/2`B>"(@72`F)B!S
M879E7U5315(])%5315(*("!;(")X)$U!2T5?34]$12(@(3T@(g...@b(%T@)B8@
M"1#5E-23T]4
M(B`A/2`B>"(@72`F)B!S879E7T-64U)/3U0])$-64U)/3U0*"B`@&5C(#,^
M)%1-4$1)4B\D0D%40TA30U))4%0*("!E8VAO($!E8VAO(&]F9B`^)C,*("`C
M(&-A=71I;VX@(2$A"B`@(R!E=F%L=6%T:6]N('-E2](2T597TQ/0T%,7TU!0TA)3D4O4UE35$5-+T-U2!A;f...@8g5i;&1S(&$@'!O'!O"(@72`F)B!E>'!O"1S879E7TE.1D]0
M051((B`A/2`B>"(@72`F)B!E>'!O'!O"1S879E7TU!2T5?34]$12(@(3T@(g...@b(%T@)b...@97ap;W)T($U!
M2T5?34]$13TD'!O"1S879E7T-64U)/3U0B("$](")X(B!=("8F(&5X<&]R="!#5E-23T]4/21S
M879E7T-64U)/3U0*("!U;G-E="!S879E7T-64U)/3U0*"B`@(R!C:&%N9VEN
m9r!4...@86yd(%1%...@=&\...@8weg=ven(&9O6=P871H("UU
M("(D5$5-4")@"@H@(",@http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: question about cygwin package
I have a last question that might reminds you something (at least I hope
so)
and unfortunately that is beyond this mailing list but I chance it
I am working on a msys/mingw installer(EasyMingw) where instead of the
default crappy
toolchain(very personal opinion I encourage you to make yours) I am
integrating mingw-w64 toolchain(32 and 64 bit).
I have one issue about mount point and since msys and cygwin have the same
ancestor maybe you know what is wrong.
So I have adopted the following tree hierarchy :
./bin
./etc
./home
./include
./lib
./mingw{32,64}
./postinstall
./sbin
./share
/mingw{32,64} holds all the "mingw" packages since it's better(not
mandatory) to separate msys from mingw
and I have declared mount points like this :
C:/Developer/EasyMingw/etc /mingw32/etc
C:/Developer/EasyMingw/mingw32/bin /mingw32/usr/bin
C:/Developer/EasyMingw/mingw32/lib /mingw32/usr/lib
So following cygwin logic I made my package inside usr folder, however I
have one issue with gcc because I get
$ gcc test.c
gcc.exe: CreateProcess: No such file or directory
If instead of putting gcc files inside a usr folder I put it directly the
archive root it works fine.
If you remember that kind of issue, please let me know.
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[OT] Re: question about cygwin package
On 27/02/2010 18:19, Vincent Richomme wrote: > $ gcc test.c > gcc.exe: CreateProcess: No such file or directory > > If instead of putting gcc files inside a usr folder I put it directly the > archive root it works fine. Add '-v' to see how gcc is using relative paths to look for cc1.exe (and presumably failing). The relative layout of the various installed files must match what was specified in the configure options for relocating an installation to work, bascially you have to move the entire thing wholesale. [ Any further posts on this topic -> TITTTL. Reply-to set. ] cheers, DaveK -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin's svn appends unwanted .exe to file name on checkout
On 2/27/2010 10:05 AM, Dave Korn wrote: On 26/02/2010 22:45, David Rothenberger wrote: I know the Cygwin DLL has some "magic" for appending the .exe extension and I suspect that's getting in the way here, but I don't know when or why it happens. I believe it happens a lot more if you go using DOS paths(*). Do not do that. That was my guess at first, but I cannot reproduce the problem using DOS paths for the repository and Alan can reproduce the problem using Cygwin paths for the repository. -- David Rothenberger daver...@acm.org -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: test for hard links always fail with pdksh
Christopher Faylor a écrit : On Thu, Feb 25, 2010 at 01:05:06PM +0100, Corinna Vinschen wrote: On Feb 25 01:30, Paul McFerrin wrote: A new wrinkle with hard links. If you are testing for them in pdksh, they will always fail. I.E.: if test -L links/$filename.$inumb then : else ln $filename $filename.$inumb fi The above test will always fail and thus will always attempt to re-create the hard link. $ man test test -L tests for symbolic links, not for hardlinks. So both the program and the documentation are wrong??? Who'd have thought it? !!! man ksh test expression [ expression ] -h file file is a symbolic link. -L file file is a symbolic link. Regards, Cyrille Lefevre -- mailto:cyrille.lefevre-li...@laposte.net -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Non-canonical mode input via tcsetattr(), under mintty console
Hi all, I was testing a program that uses non-canonical mode input via tcsetattr(). The intent of the program is: (1) have read() to wait if nothing has been entered; (2) read() should not return until 1 character is read and put into the buffer. The essence is this: > struct termios newtty; > . > . > . > tcgetattr (0, &newtty); > newtty.c_lflags &= (~ICANON); > > newtty.c_cc[VMIN] = 1; > newtty.c_cc[VTIME] = 0; > > tcsetattr (0, TCSANOW, &newtty); > > unsigned char buf[100]; > size_t n = read (0, buf, sizeof(buf)); > . > . > . I had no problem while entering an ASCII character. I also had success if I entered a non-ASCII character under standard console, but not under mintty. Specifically, I entered the chinese character "例" (which means "rule" or "example"). It occupies 3 bytes in UTF-8 representation: E4, BE, 8B. On standard console, the read() call returned THREE bytes (n == 3), and (not surprisingly) E4, BE and 8B were returned to buf[]. On mintty console, the read() call returned ONE byte (n == 1), and only E4 were returned to buf[]. I could grab the other two bytes if I did additional calls to read(). I have attached a sample program for testing purpose. Basically it waits for input, and when something is entered, prints it. Instruction is included in the source. I suspected this is a bug shown under mintty (but not standard console). Is it the case? Thanks, Dave Lee. termex.c Description: Binary data -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Non-canonical mode input via tcsetattr(), under mintty console
Sorry for forgetting 3 things. 1. I was testing on cygwin 1.7. 2. I was running the latest version of mintty (0.5.8-1). 3. I have included an output from cygcheck here. Thanks. --- On Sun, 2/28/10, Dave Lee wrote: > Hi all, > > I was testing a program that uses non-canonical mode input > via > tcsetattr(). > > The intent of the program is: > (1) have read() to wait if nothing has been entered; > (2) read() should not return until 1 character is read > and put into the buffer. > > The essence is this: > > > struct termios newtty; > > . > > . > > . > > tcgetattr (0, > &newtty); > > newtty.c_lflags &= > (~ICANON); > > > > newtty.c_cc[VMIN] = 1; > > newtty.c_cc[VTIME] = > 0; > > > > tcsetattr (0, TCSANOW, > &newtty); > > > > unsigned char > buf[100]; > > size_t n = read (0, > buf, sizeof(buf)); > > . > > . > > . > > I had no problem while entering an ASCII character. I also > had success > if I entered a non-ASCII character under standard console, > but not under > mintty. > > Specifically, I entered the chinese character "例" (which > means "rule" > or "example"). It occupies 3 bytes in UTF-8 representation: > E4, BE, 8B. > > On standard console, the read() call returned THREE bytes > (n == 3), and > (not surprisingly) E4, BE and 8B were returned to buf[]. > > On mintty console, the read() call returned ONE byte (n == > 1), and only > E4 were returned to buf[]. I could grab the other two bytes > if I did > additional calls to read(). > > I have attached a sample program for testing purpose. > Basically it waits > for input, and when something is entered, prints it. > Instruction is > included in the source. > > I suspected this is a bug shown under mintty (but not > standard > console). Is it the case? > > Thanks, > > Dave Lee. > > > -- > Problem reports: http://cygwin.com/problems.html > FAQ: > http://cygwin.com/faq/ > Documentation: http://cygwin.com/docs.html > Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple cygcheck.out Description: Binary data -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
I have a weird problem - double your files overnight with Perfect Disk - A Bug!!
This is a weird problem. Caused by interaction of cygwin 1.7 and Perfect Disk 7.0 (defragmeter). A couple of days ago, I was defragmenting my drive C: when I discovered a copy of every cygwin's file with a naming convention of: AY63D92E~orig.file.name~. The leading chars were 8 letters/numbers of uppercase. The filename portion surrounded by the "~" character. This happened only under the /cygwin tree while the MS-DOS (Win XP Pro) were unaffected. All of these files were "copies" of cygwin's files (link count == 1). Now that Perfect Disk 7.0 is done with drive C:, I'm going to delete all 47,000 of these burgers. This a weird interaction between 1.7 and Perfect Disk. The problem stopped happening when Perfect Disk finished with drive C:. This is "far" from a feature, a definite bug. One thing to note: The mtimes of all of the duplicate files were current. They did not reflect the mtime of the original file. -rwxr-xr-x 1 Paul root 259 2010-02-25 18:05 L0QHCU1M~cygwin.bat~ -rwxr-xr-x 1 Paul root 248 2010-02-26 09:31 NFP7AJAE~cygwin.bat~~ -rwxr-xr-x 1 Paul root 248 2010-02-25 18:05 QHJ5D971~cygwin.bat~~ -rwxr-xr-x 1 Paul root 259 2010-02-26 09:31 U1GLPSA4~cygwin.bat~ -rwxr-xr-x 1 Paul root 248 2010-01-25 16:14 cygwin.bat~ -rwxr-xr-x 1 Paul root 259 2010-01-25 16:28 cygwin.bat -rwxr-xr-x 1 Paul root 248 2010-02-26 09:57 97CB2MO0~QHJ5D971~cygwin.bat~~~ -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Question: about /proc/mounts
I discovered a read-only filesystem called /proc/mounts which is symbolically linked from /etc/mtab. My question is: who populates this data?? I got a cyclic-loop caused by drive C being mounted twice. as /c and /cygdrive/c I would like to get rid of the cygdrive one but it is special treatment when logoff. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Downloading cygwin 1.5.*
Should I always receive the warning dialog about 1.7 even though I *think* I'm about to download 1.5. That's a scary thought! Well this dialog is preventing me from continuing. I would feel much better if either: 1) dialog box suppressed or 2) some other feedback that I'm downloading a 1.5 instance -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
R: Downloading cygwin 1.5.*
--- Dom 28/2/10, Paul McFerrin ha scritto: > Should I always receive the warning > dialog about 1.7 even though I *think* I'm about to download > 1.5. That's a scary thought! Well this dialog is > preventing me from continuing. I would feel much > better if either: 1) dialog box suppressed or 2) some > other feedback that I'm downloading a 1.5 instance > are you running setup-legacy.exe ? That is for installing 1.5 Marco -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
