[ANNOUNCEMENT] Updated: GraphicsMagick-1.3.20-1

Version 1.3.20-1 of GraphicsMagick libGraphicsMagick-devel libGraphicsMagick3 perl-Graphics-Magick have been uploaded for cygwin DESCRIPTION GraphicsMagick is the swiss army knife of image processing. It provides a robust and efficient collection of tools and libraries which support

/bin/rbash in passwd, but starts a *non* restricted shell (1.3.20)

Interactively rbash seems to work fine: bash-2.05b$ uname -a; ln -s /bin/bash /bin/rbash;rbash CYGWIN_NT-4.0 ws011206 1.3.20(0.73/3/2) 2003-02-08 12:10 i686 unknown unknown Cygwin rbash-2.05b$ cd / rbash: cd: restricted When I set the login shell to /bin/rbash in /etc/passwd and login

/bin/rbash in passwd, but starts a *non* restricted shell (1.3.20)

Interactively rbash seems to work fine: bash-2.05b$ uname -a; ln -s /bin/bash /bin/rbash;rbash CYGWIN_NT-4.0 ws011206 1.3.20(0.73/3/2) 2003-02-08 12:10 i686 unknown unknown Cygwin rbash-2.05b$ cd / rbash: cd: restricted When I set the login shell to /bin/rbash and login through ssh the

RE: Cygwin version 1.3.20

On Mon, 21 Jul 2003, Henry Da Costa wrote: > Larry Hall wrote: > > Why do you only have the executable? Also, why can't the provider of > > this executable give you with the support you need? Strictly > > speaking, if the provider hasn't purchased a commercial license from > > Red Hat, they are

Re: Cygwin version 1.3.20

On Mon, 21 Jul 2003, Max Bowsher wrote: > Henry Da Costa wrote: > > Hello Mr. Faylor, > > You have sent this message to a public mailing list. > > > I hope you can help me. I'm looking for a complete Cygwin version 1.3.20 > > set of packages but have so far bee

RE: Cygwin version 1.3.20

Larry Hall wrote: > Why do you only have the executable? Also, why can't the provider of > this executable give you with the support you need? Strictly > speaking, if the provider hasn't purchased a commercial license from > Red Hat, they are legally bound by the GPL. If they aren't providing >

Re: Cygwin version 1.3.20

Henry Da Costa wrote: Elfyn McBratney wrote: I will add this though: If you have a program that worked on 1.3.20* which does not work on 1.3.22* it's more productive to try and find out the cause of the problem rather than going back in time. If it turns out to be a problem in the Cygwi

RE: Cygwin version 1.3.20

Elfyn McBratney wrote: > I will add this though: If you have a program that worked on 1.3.20* which does > not work on 1.3.22* it's more productive to try and find out the cause of the > problem rather than going back in time. If it turns out to be a problem in the > Cygwin DLL, m

RE: Cygwin version 1.3.20

should have > been more vigilant. Perhaps reading that pege in it's entirity (I mean the bottom of) would have helped. > > The phrase "complete Cygwin version 1.3.20 set of packages" is > meaningless. > > A Cygwin DLL version number does not uniquely identify a set of

RE: Cygwin version 1.3.20

Max Bowsher wrote: > You have sent this message to a public mailing list. Thanks for replying. I didn't realize that the "Christopher Faylor" link at http://www.cygwin.com/ led to the cygwin mailing list. I should have been more vigilant. > The phrase "complete Cy

Re: Cygwin version 1.3.20

Henry Da Costa wrote: > Hello Mr. Faylor, You have sent this message to a public mailing list. > I hope you can help me. I'm looking for a complete Cygwin version 1.3.20 > set of packages but have so far been unable to find it. The phrase "complete Cygwin version 1.3.20

Cygwin version 1.3.20

Hello Mr. Faylor, I hope you can help me. I'm looking for a complete Cygwin version 1.3.20 set of packages but have so far been unable to find it. I need that particular version of Cygwin because other versions including the latest one give us an error when used from a development tool for

Re: 1.3.20 : getpgid returns pid != -1 when specified pid no longer exists

On Wed, Apr 02, 2003 at 06:43:16PM -0800, gavin bowlby wrote: >>Ok. In that event, please provide a simple test case. > >Here's a short program to recreate this problem: > >("main.c") >= >int main(int argc, char *argv[]) { > > int pid, sid, rc;

Re: 1.3.20 : getpgid returns pid != -1 when specified pid no longer exists

>Ok. In that event, please provide a simple test case. Christopher, Corinna: Thanks for you help on this! Here's a short program to recreate this problem: ("main.c") = int main(int argc, char *argv[]) { int pid, sid, rc; if ((pid = fo

Re: 1.3.20 : getpgid returns pid != -1 when specified pid no longer exists

On Wed, Apr 02, 2003 at 12:20:56PM -0800, gavin bowlby wrote: >Thanks for your suggestion. Sorry I didn't upgrade before reporting >this problem. I still see the same problem with 1.3.22. Ok. In that event, please provide a simple test case. cgf -- Unsubscribe info: http://cygwin.com/ml/

Re: 1.3.20 : getpgid returns pid != -1 when specified pid no longer exists

6 unknown unknown Cygwin Thanks again for your help, Gavin Bowlby ([EMAIL PROTECTED]) == On Tue, Apr 01, 2003 at 07:06:45PM -0800, gavin bowlby wrote: > $ uname -a > CYGWIN_NT-5.0 reptilicus 1.3.20(0.73/3/2) 2003-02-08 > 12:10 i686 unknown

Re: 1.3.20 : getpgid returns pid != -1 when specified pid no longer exists

On Tue, Apr 01, 2003 at 07:06:45PM -0800, gavin bowlby wrote: > $ uname -a > CYGWIN_NT-5.0 reptilicus 1.3.20(0.73/3/2) 2003-02-08 > 12:10 i686 unknown unknown > Cygwin Could you test with 1.3.22 please? Corinna -- Corinna Vinschen Please, send mails regarding Cygw

1.3.20 : getpgid returns pid != -1 when specified pid no longer exists

$ uname -a CYGWIN_NT-5.0 reptilicus 1.3.20(0.73/3/2) 2003-02-08 12:10 i686 unknown unknown Cygwin Windows 2K box. Process A creates Process B. I kill Process B with a "kill -9 " Process A then does a: sid = getpgid(pid)); pid is set to process B's pid sid is not returned as

1.3.20-1: execvp does not consider relative symlinks on network shares

Hi, I am using cygwin-1.3.20-1 on a W2K machine, as another UNIX OS on a UNIX network viewed via Samba 2.0. When creating relative symlinks on the local drive (e.g., c:\), execvp finds the script through the symlink. When creating a similar relative symlink on the network share, execvp skips

Re: DBDOracle error on 1.3.22, ok on 1.3.20

: "Bruce Dobrin" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, March 25, 2003 5:59 PM Subject: DBDOracle error on 1.3.22, ok on 1.3.20 > I just upgraded from 1.3.20 to 1.3.22 and noticed the the DBDoracle module > (1.13 and 1.12( Oracle.dll) fails on the new v

DBDOracle error on 1.3.22, ok on 1.3.20

I just upgraded from 1.3.20 to 1.3.22 and noticed the the DBDoracle module (1.13 and 1.12( Oracle.dll) fails on the new version. I tried recompiling agianst the same libraries on both cygwins, and though the compile gives the same output and result under both, the dll fails to load under

Re: 1.3.20: [incr Tcl/Tk] interpreters missing - second try

d. Please help. > > Cygwin DLL version info: > DLL version: 1.3.20 > tcltk20030214-1 > > Best regards, > > Jerzy Witkowski > > > > -- > Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple > Bug reporting:

1.3.20: [incr Tcl/Tk] interpreters missing - second try

plied. Please help. Cygwin DLL version info: DLL version: 1.3.20 tcltk20030214-1 Best regards, Jerzy Witkowski -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation:

RE: cygwin 1.3.20-1 - strange problems with long command lines innt4

Matt, Re: the g++ problem, looks like you're missing "c:\cygwin\bin" from your system (windows) PATH. As for your original problem, since noone else here is able to reproduce it, would you be willing to try compiling bash from sources and inserting some debugging output? It would be interesting

RE: cygwin 1.3.20-1 - strange problems with long command lines in nt4

On Wed, 12 Mar 2003, Randall R Schulz wrote: > At 16:00 2003-03-12, Igor Pechtchanski wrote: > >On Wed, 12 Mar 2003, Randall R Schulz wrote: > > > >... > > > > > >Just got another idea. See if this helps: > > > > > > > > > > I believ

RE: cygwin 1.3.20-1 - strange problems with long command lines in nt4

I find that I can successfully pass long args to echo.exe using the @arglist method. It is not too convenient though as using cmd.exe for a shell is pretty awful. And I couldn't get g++ to work under cmd.exe ("The dynamicl link library cygwin1.dll could not be found...") For the time being, I gues

RE: cygwin 1.3.20-1 - strange problems with long command lines in nt4

At 16:00 2003-03-12, Igor Pechtchanski wrote: On Wed, 12 Mar 2003, Randall R Schulz wrote: ... > >Just got another idea. See if this helps: > > > > I believe the @argFileName syntax only works when a non-Cygwin program > invokes a C

RE: cygwin 1.3.20-1 - strange problems with long command lines in nt4

On Wed, 12 Mar 2003, Randall R Schulz wrote: > Igor, > > At 15:24 2003-03-12, Igor Pechtchanski wrote: > >On Wed, 12 Mar 2003, Willis, Matthew wrote: > > > >... > > > > > which will run when I pass long arguments using bash.exe as my shell. I can > > > also pass long arguments to this program unde

RE: cygwin 1.3.20-1 - strange problems with long command lines in nt4

Igor, At 15:24 2003-03-12, Igor Pechtchanski wrote: On Wed, 12 Mar 2003, Willis, Matthew wrote: ... > which will run when I pass long arguments using bash.exe as my shell. I can > also pass long arguments to this program under cmd.exe. The only difference > seems to be that bash.exe fully expand

RE: cygwin 1.3.20-1 - strange problems with long command lines in nt4

On Wed, 12 Mar 2003, Willis, Matthew wrote: > > Igor wrote: > > You may be hitting the command-line limit with bash. Try the above with > > cmd.exe. See below. > >> c:\cygwin\bin\echo.exe %PATH%-- works fine > >> c:\cygwin\bin\echo.exe %PATH%%PATH% -- fails, immediately returns to > com

RE: cygwin 1.3.20-1 - strange problems with long command lines in nt4

> Igor wrote: > You may be hitting the command-line limit with bash. Try the above with > cmd.exe. See below. >> c:\cygwin\bin\echo.exe %PATH%-- works fine >> c:\cygwin\bin\echo.exe %PATH%%PATH% -- fails, immediately returns to command line > >Try stracing the last line above... >

RE: cygwin 1.3.20-1 - strange problems with long command lines in nt4

On Wed, 12 Mar 2003, Willis, Matthew wrote: > Igor wrote: > > >Matt, > > > >A virus checker *shouldn't* affect your command line length limit... > >Try running the offending command under strace, e.g., > > > >strace -o echo.strace /usr/bin/echo ${PATH}${PATH} > > > >and look at the tail of the out

RE: cygwin 1.3.20-1 - strange problems with long command lines in nt4

Igor wrote: >Matt, > >A virus checker *shouldn't* affect your command line length limit... >Try running the offending command under strace, e.g., > >strace -o echo.strace /usr/bin/echo ${PATH}${PATH} > >and look at the tail of the output. That should give you a clue of where >it's hanging. If y

Re: cygwin/1.3.20-1 bash child process disassociation behavior weirdness

> Resent-To: [EMAIL PROTECTED] > Resent-From: [EMAIL PROTECTED] > Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm > Sender: [EMAIL PROTECTED] > Mail-Followup-To: [EMAIL PROTECTED] > X-Injected-Via-Gmane: http://gmane.org/ > From: Thorsten Kampe <[EMAIL PROTECTED]> > Date: Tue, 11 Mar

Re: cygwin 1.3.20-1 - strange problems with long command lines in nt4

ortion of the cc1plus command; that would work. The > g++-2.exe command worked most of the time, unless you had a makefile with > many object files. (Theory: intermediary command lines were shorter with > g++-2.exe?). I could work around the too-many-object-files issue in my > makef

cygwin 1.3.20-1 - strange problems with long command lines in nt4

ry: intermediary command lines were shorter with g++-2.exe?). I could work around the too-many-object-files issue in my makefile by using "ar rv" to create libs, one object file at a time. Since I updated to 1.3.20-1, I find the "magic" number of characters has dropped t

Re: cygwin/1.3.20-1 bash child process disassociation behavior weirdness

* Francis Litterio (03-03-11 21:03 +0100) > Max Bowsher wrote: >> Richard H. Broberg wrote: >>> In the meantime I'll >>> happily use rxvt in place of bash, since it does what I need. >> >> You are confused. >> >> rxvt is a terminal. >> bash is a shell. > > Looked at another way: > > rxvt is

Re: cygwin/1.3.20-1 bash child process disassociation behaviorweirdness

Max Bowsher wrote: > Richard H. Broberg wrote: >> In the meantime I'll >> happily use rxvt in place of bash, since it does what I need. > > You are confused. > > rxvt is a terminal. > bash is a shell. Looked at another way: rxvt is a GUI application. bash is a console application

Re: cygwin/1.3.20-1 bash child process disassociation behavior weirdness

> Resent-To: [EMAIL PROTECTED] > Resent-From: [EMAIL PROTECTED] > From: "Max Bowsher" <[EMAIL PROTECTED]> [snip] > > Richard H. Broberg wrote: > > In the meantime I'll > > happily use rxvt in place of bash, since it does what I need. > > You are confused. > > rxvt is a terminal. > ba

Re: 1.3.20: cdda2wav -paranoia crashes 2000/XP

r file sets before writing them to a CD). Randall Schulz At 03:22 2003-03-10, [EMAIL PROTECTED] wrote: Hi everybody, could somebody with Win2K/XP and cygwin1.dll 1.3.20 please try this: insert an audio-cd into your cd-rom/cd-writer enter the following: cd /tmp (or whatever) cdrecord -scanbu

Re: cygwin/1.3.20-1 bash child process disassociation behavior weirdness

Richard H. Broberg wrote: > In the meantime I'll > happily use rxvt in place of bash, since it does what I need. You are confused. rxvt is a terminal. bash is a shell. You are very likely running bash in rxvt. Max. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporti

Re: cygwin/1.3.20-1 bash child process disassociation behavior weirdness

> Resent-To: [EMAIL PROTECTED] > Resent-From: [EMAIL PROTECTED] > From: "Max Bowsher" <[EMAIL PROTECTED]> > Date: Sat, 8 Mar 2003 01:17:25 - [snip] > > Richard H. Broberg wrote: > >> From: "Max Bowsher" <[EMAIL PROTECTED]> > >> > >> An unfortunate consequence of how Windows handles

1.3.20: cdda2wav -paranoia crashes 2000/XP

Hi everybody, could somebody with Win2K/XP and cygwin1.dll 1.3.20 please try this: insert an audio-cd into your cd-rom/cd-writer enter the following: cd /tmp (or whatever) cdrecord -scanbus (gives you a list of devices) cdda2wav dev=1,5,0 -paranoia -B (modify "dev") Be warned: you

Re: cygwin/1.3.20-1 bash child process disassociation behavior weirdness

Please keep replies on the list. Richard H. Broberg wrote: >> From: "Max Bowsher" <[EMAIL PROTECTED]> >> >> An unfortunate consequence of how Windows handles console windows. >> >> I believe it would be possible to write an alternative >> implementation of nohup using fork/setsid, or perhaps e

Re: cygwin/1.3.20-1 bash child process disassociation behavior weirdness

* Richard H. Broberg (03-03-07 22:47 +0100) > In non-cygwin unix I'm familiar with being able to do the following in a > shell (bash or other): > > $ nohup long-running-command & > $ exit > > and be able to leave it running. > > However, under cygwin (this has been true for at least back to cygw

Re: cygwin/1.3.20-1 bash child process disassociation behavior weirdness

Christopher Faylor wrote: > On Fri, Mar 07, 2003 at 06:17:17PM -0500, Igor Pechtchanski wrote: >> On Fri, 7 Mar 2003, Max Bowsher wrote: >>> Christopher Faylor wrote: This works for me: nohup sleep 30 foo 2>&1& at least with the latest version of cygwin... >>> >>> Doesn'

Re: cygwin/1.3.20-1 bash child process disassociation behavior weirdness

On Fri, Mar 07, 2003 at 06:17:17PM -0500, Igor Pechtchanski wrote: >On Fri, 7 Mar 2003, Max Bowsher wrote: >> Christopher Faylor wrote: >> > On Fri, Mar 07, [EMAIL PROTECTED]:00:28PM -, Max Bowsher wrote: >> >> Richard H. Broberg wrote: >> >>> In non-cygwin unix I'm familiar with being able to

Re: cygwin/1.3.20-1 bash child process disassociation behavior weirdness

On Fri, 7 Mar 2003, Max Bowsher wrote: > Christopher Faylor wrote: > > On Fri, Mar 07, [EMAIL PROTECTED]:00:28PM -, Max Bowsher wrote: > >> Richard H. Broberg wrote: > >>> In non-cygwin unix I'm familiar with being able to do the following > >>> in a shell (bash or other): > >>> > >>> $ nohup

Re: cygwin/1.3.20-1 bash child process disassociation behavior weirdness

Works for me using rxvt. "Richard H. Broberg" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > > In non-cygwin unix I'm familiar with being able to do the following in a > shell (bash or other): > > $ nohup long-running-command & > $ exit > > and be able to leave it running. > > Howev

Re: cygwin/1.3.20-1 bash child process disassociation behavior weirdness

Works for me using rxvt. "Richard H. Broberg" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > > In non-cygwin unix I'm familiar with being able to do the following in a > shell (bash or other): > > $ nohup long-running-command & > $ exit > > and be able to leave it running. > > Howev

Re: cygwin/1.3.20-1 bash child process disassociation behavior weirdness

Christopher Faylor wrote: > On Fri, Mar 07, 2003 at 10:00:28PM -, Max Bowsher wrote: >> Richard H. Broberg wrote: >>> In non-cygwin unix I'm familiar with being able to do the following >>> in a shell (bash or other): >>> >>> $ nohup long-running-command & >>> $ exit >>> >>> and be able to le

Re: cygwin/1.3.20-1 bash child process disassociation behavior weirdness

On Fri, Mar 07, 2003 at 10:00:28PM -, Max Bowsher wrote: >Richard H. Broberg wrote: >> In non-cygwin unix I'm familiar with being able to do the following >> in a shell (bash or other): >> >> $ nohup long-running-command & >> $ exit >> >> and be able to leave it running. >> >> However, under cy

Re: cygwin/1.3.20-1 bash child process disassociation behavior weirdness

Richard H. Broberg wrote: > In non-cygwin unix I'm familiar with being able to do the following > in a shell (bash or other): > > $ nohup long-running-command & > $ exit > > and be able to leave it running. > > However, under cygwin (this has been true for at least back to > cygwin/1.3.6 for me), w

cygwin/1.3.20-1 bash child process disassociation behavior weirdness

In non-cygwin unix I'm familiar with being able to do the following in a shell (bash or other): $ nohup long-running-command & $ exit and be able to leave it running. However, under cygwin (this has been true for at least back to cygwin/1.3.6 for me), when I start a process in the background an

RE: 1.3.20: bug: UID over 65536: I have no name!

Date: Thu, 6 Mar 2003 14:21:33 +0800 To: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: RE: 1.3.20: bug: UID over 65536: "I have no name!" Hello, Even after changing my UID in /etc/passwd from 65558 to 22, I still get the following permission errors when I open a she

Re: 1.3.20-1: signal 11 when compiling XEmacs-2.4.12

ronment dump, I'm still using gcc3). So, I insist: there is a bug in >1.3.20-1 (reproducable by building xemacs-21.4.12) that has not been in >1.3.18. I have loosly followed this thread... I have had a similar problem after updating to 1.3.20. When compiling I got random signal 11 cras

Re: 1.3.20 gcc cannot exec cc1 update

On Fri, Mar 07, 2003 at 01:23:22PM +0100, Michael Graff Andersen wrote: >Hello > >I have made a little progress, I found mail about a problem similar to >mine > >The solution was: >chmod a+x /bin >chmod a+x /lib/gcc-lib/i686-pc-cygwin/3.2/ > >now I get >gcc hello.c -o hello >/usr/lib/gcc-lib/i686

Re: 1.3.20-1: signal 11 when compiling XEmacs-2.4.12

t dump, I'm still using gcc3). So, I insist: there is a bug in >1.3.20-1 (reproducable by building xemacs-21.4.12) that has not been in >1.3.18. Perhaps. But, for the record, it is very unlikely that anyone here is going to download the Xemacs sources and attempt a compilation. If y

Re: 1.3.20-1 CYGWIN ; csh,bash and ./config

permissions to the executable and re-'make' the program_exe was build finally. Best, Konstantinos From: Igor Pechtchanski <[EMAIL PROTECTED]> Reply-To: [EMAIL PROTECTED] To: Konstantinos Makrodimitris <[EMAIL PROTECTED]> CC: [EMAIL PROTECTED] Subject: Re: 1.3.20-1 CYGWIN ;

1.3.20 gcc cannot exec cc1 update

Hello I have made a little progress, I found mail about a problem similar to mine The solution was: chmod a+x /bin chmod a+x /lib/gcc-lib/i686-pc-cygwin/3.2/ now I get gcc hello.c -o hello /usr/lib/gcc-lib/i686-pc-cygwin/3.2/../../../../i686-pc-cygwin/bin/ld: cannot open crt0.o: No such file

Re: 1.3.20-1: signal 11 when compiling XEmacs-2.4.12

Hi Rick, I think you are missing an important point: I can build xemacs successfully when I use the older (1.3.18) cygwin1.ddl! That's the only thing I have changed about the environment (as you can see in the environment dump, I'm still using gcc3). So, I insist: there is a bug in

Re: 1.3.20-1: signal 11 when compiling XEmacs-2.4.12

PROTECTED]> wrote: > Hi, > > after upgrading to cygwin 1.3.20-1, I noticed that my XEmacs 2.4.11 > crashes under unreproducable circumstances. So I though OK, upgrade > XEmacs to 2.4.12, maybe this helps. > > I downloaded the XEmacs 2.4.12 sources from www.xemacs.org, un

1.3.20-1: signal 11 when compiling XEmacs-2.4.12

Hi, after upgrading to cygwin 1.3.20-1, I noticed that my XEmacs 2.4.11 crashes under unreproducable circumstances. So I though OK, upgrade XEmacs to 2.4.12, maybe this helps. I downloaded the XEmacs 2.4.12 sources from www.xemacs.org, unpacked and configured with "./configure --with-ms

Re: 1.3.20-1 CYGWIN ; csh,bash and ./config

Randal, Igor, On Wed, Mar 05, 2003 at 08:15:09AM -0800, Randall R Schulz wrote: > If you're asking me, I'd say it's probably a good idea. It would > probably help keep lunkheads like me from doing stupid things like > copying tcsh to csh... I've uploaded a new release with a postinstall script.

1.3.20 gcc cannot exec cc1

"cygreadline4.dll" v0.0 ts=2001/1/7 5:34 127k 2002/10/10 c:\cygwin\bin\cygreadline5.dll - os=4.0 img=1.0 sys=4.0 "cygreadline5.dll" v0.0 ts=2002/10/10 19:28 50k 2002/03/12 c:\cygwin\bin\cygz.dll - os=4.0 img=1.0 sys=4.0 "cygz.d

Re: 1.3.20: bug: UID over 65536: "I have no name!"

[EMAIL PROTECTED] wrote: > Hello, > > Even after changing my UID in /etc/passwd from 65558 to 22, I still get the > following permission errors when I open a shell: > > /usr/share/texmf/ls-R: Permission denied > /usr/share/texmf/aliases: Permission denied > > Also, my .bashrc file in my home di

RE: 1.3.20: bug: UID over 65536: "I have no name!"

being recognized. (B (BBest regards, (BFred Ulmer (B (B (B-Original Message- (BFrom: Larry Hall (RFK Partners, Inc.) [mailto:[EMAIL PROTECTED] (BSent: Thursday, March 06, 2003 3:15 PM (BTo: Keith Hopkins (BCc: [EMAIL PROTECTED]; [EMAIL PROTECTED] (BSubject: Re: 1.3.20: bug: UID over

Re: 1.3.20: bug: UID over 65536: "I have no name!"

Keith Hopkins wrote: Hi! 1.3.20-1 on Win2k, downloaded 20030306. I saw this when a friend of mine, and myself were trying to install 1.3.20 yesterday (dl, then install from dl). The install would go fine, but when you started the shell, $UID would have dropped the high bits from the NT

1.3.20: bug: UID over 65536: "I have no name!"

Hi! 1.3.20-1 on Win2k, downloaded 20030306. I saw this when a friend of mine, and myself were trying to install 1.3.20 yesterday (dl, then install from dl). The install would go fine, but when you started the shell, $UID would have dropped the high bits from the NT-DOMAIN UID. For example

1.3.20 and 1.3.19, can't compile || can't find /bin/sh

s was with 1.3.20. I found that others had the same problem on the mailing list archives, and one person mentioned that going back to 1.3.19 fixed the problem for him. I removed my cygwin folder and the registry keys, and reinstalled the same packages as before, but this time selecting cygwin 1

Re: 1.3.20-1 CYGWIN ; csh,bash and ./config

Corinna, At 08:04 2003-03-05, Corinna Vinschen wrote: ... Would you think it makes sense to create a csh symlink to tcsh.exe in the package? Seems to be common on Linux at least. If you're asking me, I'd say it's probably a good idea. It would probably help keep lunkheads like me from doing stu

Re: 1.3.20-1 CYGWIN ; csh,bash and ./config

On Wed, 5 Mar 2003, Corinna Vinschen wrote: > > At 01:47 2003-03-05, Corinna Vinschen wrote: > > >P.S.: No, it doesn't. Create your own symlink or change the first > > >script line to `#!/bin/tcsh' > > Would you think it makes sense to create a csh symlink to tcsh.exe in > the package? Seems to

Re: 1.3.20-1 CYGWIN ; csh,bash and ./config

On Wed, Mar 05, 2003 at 07:38:17AM -0800, Randall R Schulz wrote: > At 01:47 2003-03-05, Corinna Vinschen wrote: > >P.S.: No, it doesn't. Create your own symlink or change the first > >script line to `#!/bin/tcsh' > > Corinna, Igor, > > I wonder what this means: > > % ll /bin/{t,}csh.exe > -rwx

Re: 1.3.20-1 CYGWIN ; csh,bash and ./config

At 01:47 2003-03-05, Corinna Vinschen wrote: On Tue, Mar 04, 2003 at 03:20:52PM -0500, Igor Pechtchanski wrote: > Konstantinos, > > First off, the script is written for csh. Why would you expect sh or bash > to be able to interpret it? These shells use different syntax. > > The original script fa

Re: 1.3.20-1 CYGWIN ; csh,bash and ./config

On Wed, 5 Mar 2003, Corinna Vinschen wrote: > On Tue, Mar 04, [EMAIL PROTECTED]:20:52PM -0500, Igor Pechtchanski wrote: > > Konstantinos, > > > > First off, the script is written for csh. Why would you expect sh or bash > > to be able to interpret it? These shells use different syntax. > > > > T

Re: 1.3.20-1 CYGWIN ; csh,bash and ./config

On Tue, Mar 04, 2003 at 03:20:52PM -0500, Igor Pechtchanski wrote: > Konstantinos, > > First off, the script is written for csh. Why would you expect sh or bash > to be able to interpret it? These shells use different syntax. > > The original script failed because you don't have csh installed.

Re: 1.3.20-1 CYGWIN ; csh,bash and ./config

Konstantinos Makrodimitris wrote: > I am trying to run a configure file > ./config Cygwin-i686 > The file “config” is like: > _ > #!/bin/csh -f > Changing the first line of the “config” in sh mode > #!/bin/sh –f You do realize

Re: 1.3.20-1 CYGWIN ; csh,bash and ./config

Konstantinos, First off, the script is written for csh. Why would you expect sh or bash to be able to interpret it? These shells use different syntax. The original script failed because you don't have csh installed. Cygwin does not have a "csh" package, but it does have a "tcsh" package that m

1.3.20-1 CYGWIN ; csh,bash and ./config

Hi, I am trying to run a configure file ./config Cygwin-i686 in order then to : cd Cygwin-i686 make The file “config” is like: _ #!/bin/csh -f goto begin syntax: echo '' echo 'Usage: config [debug] [tcl] [fftw] [/][.comment]'

1.3.20: .rhosts is ignored by cygwin

I'm trying to do a rsh without password but cygwin replies "Permission Denied" message. So I've created a .rhosts file in the home directory of the user who I'm using to do the rsh containing a "+" symbol. CYGWIN creates a file with 777 rights permissions, but I've changed to 600 and 644 without s

Re: cygwin-1.3.20-1 breaks termcaps [actually permissions break them]

On Wednesday, February 26, 2003 at 17:14:24, Ronald Landheer-Cieslakq wrote: [...] > > Has someone a script to fix the permissions of all standard > > files to a reasonable value instead of +rx for all dirs and > > +r for all files? > $ chmod -R a+r * > ? > > or > $ find -type d -exec chmod go+rx

Re: 1.3.20 most recent upgrades : rxvt creates 100% load on CPU

1/2003 03:53 PM Please respond to cygwin To: Jurgen Defurne/BRG/CE/[EMAIL PROTECTED] cc: [EMAIL PROTECTED] Subject: Re: 1.3.20 most recent upgrades : rxvt creates 100% load on CPU Classification: On Fri, 21 Feb 2003 [EMAIL PROTECTED] wrote: &

Re: cygwin-1.3.20-1 breaks termcaps, Re: Re: cygwin-1.3.20-1 breakstermcaps

On Wed, 26 Feb 2003 [EMAIL PROTECTED] wrote: > On Wednesday, February 26, 2003 at 13:15:54, Ronald Landheer-Cieslak wrote: > > This won't help you fix your problem, but might stop you from > > running into new ones.. (see below) > o.k. so I keep with one installation ... Good. :) > On Wednesday, F

Re: cygwin-1.3.20-1 breaks termcaps,Re: Re: cygwin-1.3.20-1 breaks termcaps

On Wednesday, February 26, 2003 at 13:15:54, Ronald Landheer-Cieslak wrote: > This won't help you fix your problem, but might stop you from > running into new ones.. (see below) o.k. so I keep with one installation ... > On Tue, 25 Feb 2003 [EMAIL PROTECTED] wrote: [...] > You *cannot* have two d

1.3.20: [incr Tcl/Tk] interpreters missing

amed `tclsh.exe' and `wish.exe', but I cannot find the last ones. It is strange, because the compile libraries (e.g. lib/libitcl.a) and startup files (e.g. usr/share/itcl3.2/) for them are still supplied. Please help. Cygwin DLL version info: DLL version: 1.3.20 tcltk

Re: cygwin-1.3.20-1 breaks termcaps

On Tue, 18 Feb 2003 [EMAIL PROTECTED] wrote: > > > [...] > > > > Umm, you could provide your actual system configuration (the > > > > output of "cygcheck -svr") as a *non-compressed* text *attachment* > > > > (as per <http://cygwin.com/bugs.html>). > >

Re: cygwin-1.3.20-1 breaks termcaps

t; > > On Tue, 18 Feb 2003 [EMAIL PROTECTED] wrote: > > [...] > > > Umm, you could provide your actual system configuration (the > > > output of "cygcheck -svr") as a *non-compressed* text *attachment* > > > (as per <http://cygwin.com/bugs.html>)

Re: cygwin-1.3.20-1 breaks termcaps

uot;cygcheck -svr") as a *non-compressed* text *attachment* > > (as per <http://cygwin.com/bugs.html>). > > Igor > > Here it is the good 1.30.19-1 and the bad 1.3.20-1 Hmm, still having the problem. After upgrading to 1.3.20-1, I just copied the old version of cygwin

Re: 1.3.20: mmap with nonzero file offset results in seg fault (W in2k )"

On Tue, Feb 25, 2003 at 01:16:02AM -0500, Christopher Faylor wrote: > On Tue, Feb 25, 2003 at 04:51:33PM +1100, [EMAIL PROTECTED] wrote: > >The seg fault only occurs in version 1.3.20. The TEST_FILE macro needs > >to be set to the name of a file that is larger than 16 system page

Re: 1.3.20 most recent upgrades : rxvt creates 100% load on CPU

1/2003 03:53 PM Please respond to cygwin To: Jurgen Defurne/BRG/CE/[EMAIL PROTECTED] cc: [EMAIL PROTECTED] Subject: Re: 1.3.20 most recent upgrades : rxvt creates 100% load on CPU Classification: On Fri, 21 Feb 2003 [EMAIL PROTECTED] wrote: &

Re: 1.3.20: mmap with nonzero file offset results in seg fault (W in2k )"

prot, MAP_SHARED, fd, offset) == MAP_FAILED) It should be: if ((rslt = mmap(0, size, prot, MAP_SHARED, fd, offset)) == MAP_FAILED) >The seg fault only occurs in version 1.3.20. The TEST_FILE macro needs >to be set to the name of a file that is larger than 16 system pages + >32 bytes. Al

RE: 1.3.20: mmap with nonzero file offset results in seg fault (Win2k )"

never 0." - mmap man page Despite your warm welcome to the group, I have attached a full test case. After further inspection it appears that the seg fault only occurs if the file offset is greater than 16 system pages. The seg fault only occurs in version 1.3.20. The TEST_FILE macro needs t

Re: 1.3.20: mmap with nonzero file offset results in seg fault (Win2k )"

On Tue, Feb 25, 2003 at 12:49:45PM +1100, [EMAIL PROTECTED] wrote: > >Accessing the mapped region of memory after an mmap call >with a non-zero offset results in a seg fault. A zero >offset will not result in a seg fault. > >Cygwin1.dll version 1.3.19 doesn't experience this problem. >Cygcheck

1.3.20: mmap with nonzero file offset results in seg fault (Win2k)"

Accessing the mapped region of memory after an mmap call with a non-zero offset results in a seg fault. A zero offset will not result in a seg fault. Cygwin1.dll version 1.3.19 doesn't experience this problem. Cygcheck output is attached. Example: if (rslt = mmap(0, size, prot, MAP_SHARED,

Re: cygwin 1.3.20-1 and python 2.2.2-5

On Fri, Feb 21, 2003 at 05:00:55AM -0700, [EMAIL PROTECTED] wrote: > On Thu, 20 Feb 2003 14:04:58 -0500, Christopher Faylor wrote: > >I've generate a snapshot with this fix included (thanks Corinna) > >if anyone wants to try it. > > I've replaced cygwin1.dll with 1.3.21 I presume that you mean th

1.3.20 most recent upgrades : rxvt creates 100% load on CPU

On Friday 21 Feb 03, [EMAIL PROTECTED] writes: > Hello, list, > > I was experimenting with emacs, found out about C-h and Backspace > problem, and then, in suggestion to found answers, I decided to try > rxvt. > > rxvt seems to have a load problem, however. I haven't found anything > in the maili

Re: cygwin 1.3.20-1 and python 2.2.2-5

On Thu, 20 Feb 2003 14:04:58 -0500, Christopher Faylor wrote: I've generate a snapshot with this fix included (thanks Corinna) if anyone wants to try it. I've replaced cygwin1.dll with 1.3.21 and APS now works perfectly. Thanks. Gael. -- Unsubscribe info: http://cygwin.com/ml/#unsubscrib

Re: 1.3.20 most recent upgrades : rxvt creates 100% load on CPU

On Fri, 21 Feb 2003 [EMAIL PROTECTED] wrote: > Hello, list, > > I was experimenting with emacs, found out about C-h and Backspace > problem, and then, in suggestion to found answers, I decided to try > rxvt. > > rxvt seems to have a load problem, however. I haven't found anything > in the mailing

1.3.20 most recent upgrades : rxvt creates 100% load on CPU

06/28 C:\cygwin\bin\cygreadline4.dll - os=4.0 img=1.0 sys=4.0 "cygreadline4.dll" v0.0 ts=2001/1/7 5:34 127k 2002/10/10 C:\cygwin\bin\cygreadline5.dll - os=4.0 img=1.0 sys=4.0 "cygreadline5.dll" v0.0 ts=2002/10/10 19:28 66k 2001/11/20 C:\

Re: cygwin 1.3.20-1 and python 2.2.2-5

On Thu, Feb 20, 2003 at 02:01:36PM -0500, Jason Tishler wrote: >On Tue, Feb 18, 2003 at 11:17:02PM +0300, Dmitry Rozmanov wrote: >> It looks like Cygwin has a bug. > >It was and is fixed in Cygwin CVS: > >http://cygwin.com/ml/cygwin-cvs/2003-q1/msg00252.html I've generate a snapshot with this

  1   2   >