problem with drive letters when running from DOS box

[Erich Dollansky]

Hi,

I noticed a strange problem. I tried to run 'cmp' from a DOS box but it 
could not find the file.


cmp d:\Data\file1 e:file2

did simply not see file2 even if I started cmp from e:.

As I was off-line when I needed cmp, I wrote my own cmp to compare the 
files.


What surprise. The same effect.

I investigated further just to find out that fopen does not find files 
if they do not contain '\' after the drive letter.


In the test case, E: does not contain any directories which might 
confuse fopen.


I updated cygwin last week.

cygwin1.dll is dated 31.01.2007.

Both programs work as expected when started from bash.

Erich


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: file permissions on vista

[Arnaud Legout]

Hello Brian,

Brian Dessent wrote:

I can't reproduce this.  I right click and create a new Notepad file
foo.txt, it has the permissions:
  


may be you have deactivated the UAC as morgan suggested?

The permissions on a file created with native Windows methods should
inherit from the parent folder, following standard NTFS rules, so maybe
you need to look at what the containing folder's permissions are set to.
  


I see. Indeed, the access right on the \cygwin\c was 000, then I did a 
chmod u+rwx on this folder,
but of course, vista is not aware of that and I suppose that NTFS still 
consider that c has no right,

thus any folder and file created in c:.
However, I have no idea how to manage those rights on vista.
Do you know any reasonable documentation on those access rights on vista.
Also, how are mapped the vista rights to the cygwin rights?


Thanks,
Arnaud.

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

[Fwd: Re: file permissions on vista]

[Arnaud Legout]

I forgot to CC the mailing list.

--- Begin Message ---

Hello Morgan,

morgan gangwere wrote:

1 - Turn Off UAC
  


I turned it off, and now when I create a file, the access rights are u+rwx.
Also the user is Administrator, whereas it was my username when I have 
UAC on.

So I suppose that Brian has UAC turned off.

I will definitively have to read a documentation on UAC and vista 
security model in general

to understand how flexible and configurable it is.
Otherwise, I sure that I will face other side effects.

Thanks for the tip.

Arnaud.

--- End Message ---
--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: problem with drive letters when running from DOS box

[Corinna Vinschen]

On May 27 07:49, Erich Dollansky wrote:
> Hi,
> 
> I noticed a strange problem. I tried to run 'cmp' from a DOS box but it 
> could not find the file.
> 
> cmp d:\Data\file1 e:file2

Actually we don't expect this to work.  The DOS notion of a drive relative
working directory isn't supported by Cygwin.  You should rather use POSIX
paths anyway (cmp /cygdrive/d/Data/file1 /cygdrive/e/file2).


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  cygwin AT cygwin DOT com
Red Hat

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: rsync problems with snapshots

[Corinna Vinschen]

On May 27 22:25, Angelo Graziosi wrote:
> 
> I want to flag that with the Cygwin snapshots (those of 1.7 version) there
> is this problem using rsync:
> 
> -
> $ rsync -av --delete ftp.dante.de::CTAN/systems/win32/miktex /tmp
> 
> receiving file list ... done
> rsync: read error: Socket operation on non-socket (108)
> rsync error: error in rsync protocol data stream (code 12) at
> /home/lapo/packaging/tmp/rsync-2.6.6/io.c(584)
> ---
> 
> 
> Now it seems to wait for something (almost no CPU usage) and typing
> CTRL-C:
> 
> --
> rsync error: received SIGUSR1 or SIGINT (code 20) at
> /home/lapo/packaging/tmp/rsync-2.6.6/rsync.c(163)
> --
> 
> This happens on Win XP PRO (32 bit) with all cygwin installed.

Still http://cygwin.com/ml/cygwin/2007-04/msg00155.html

Any chance that you start debugging this?


Corinna


-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  cygwin AT cygwin DOT com
Red Hat

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: problem with drive letters when running from DOS box

[Erich Dollansky]

Hi,

Corinna Vinschen wrote:

On May 27 07:49, Erich Dollansky wrote:


I noticed a strange problem. I tried to run 'cmp' from a DOS box but it 
could not find the file.


cmp d:\Data\file1 e:file2


Actually we don't expect this to work.  The DOS notion of a drive relative


it works perfectly even if the back slash is in the path.


working directory isn't supported by Cygwin.  You should rather use POSIX
paths anyway (cmp /cygdrive/d/Data/file1 /cygdrive/e/file2).


I did not know that this works when I start the program from a DOS box.

Erich

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: problem with drive letters when running from DOS box

[Erich Dollansky]

Hi,

Erich Dollansky wrote:

Hi,

Corinna Vinschen wrote:

On May 27 07:49, Erich Dollansky wrote:


I noticed a strange problem. I tried to run 'cmp' from a DOS box but 
it could not find the file.


cmp d:\Data\file1 e:file2


Actually we don't expect this to work.  The DOS notion of a drive 
relative


it works perfectly even if the back slash is in the path.


wrong English: just delete the 'even'.

Erich

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

RE: [Spam?]Re: problem concating (>>) to a large file

[Peter Milne]

Hi Eric

Were you able to reproduce the problem I encountered with dd?

Cheers
Peter




--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: problem with drive letters when running from DOS box

[Corinna Vinschen]

On May 29 13:03, Erich Dollansky wrote:
> Hi,
> 
> Corinna Vinschen wrote:
> >On May 27 07:49, Erich Dollansky wrote:
> >>
> >>I noticed a strange problem. I tried to run 'cmp' from a DOS box but it 
> >>could not find the file.
> >>
> >>cmp d:\Data\file1 e:file2
> >
> >Actually we don't expect this to work.  The DOS notion of a drive relative
> 
> it works perfectly even if the back slash is in the path.

Sure.  The backslash makes the path absolute instead of relative to the
drive's cwd.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  cygwin AT cygwin DOT com
Red Hat

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: rsync problems with snapshots

[Angelo Graziosi]

Corinna Vinschen wrote:

> Any chance that you start debugging this?


Sorry, but I have not a great experience with debugging, so when I detect
some problems I flag them to the list hoping that someone more expert look
at them.


Angelo.



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: rsync problems with snapshots

[Corinna Vinschen]

On May 29 15:21, Angelo Graziosi wrote:
> 
> Corinna Vinschen wrote:
> 
> > Any chance that you start debugging this?
> 
> 
> Sorry, but I have not a great experience with debugging, so when I detect
> some problems I flag them to the list hoping that someone more expert look
> at them.

Maybe this is a good chance to gain some debugging skills?


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  cygwin AT cygwin DOT com
Red Hat

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: File Permissions on Vista [could be "how to deal with UAC"?]

[morgan gangwere]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Arnaud Legout wrote:
> I forgot to CC the mailing list.
> 
> 
> 
> 
> Subject:
> Re: file permissions on vista
> From:
> Arnaud Legout <[EMAIL PROTECTED]>
> Date:
> Tue, 29 May 2007 09:46:52 +0200
> To:
> morgan gangwere <[EMAIL PROTECTED]>
> 
> To:
> morgan gangwere <[EMAIL PROTECTED]>
> 
> 
> Hello Morgan,
> 
> morgan gangwere wrote:
>> 1 - Turn Off UAC
>>   
> 
> I turned it off, and now when I create a file, the access rights are u+rwx.
> Also the user is Administrator, whereas it was my username when I have
> UAC on.
> So I suppose that Brian has UAC turned off.
> 
> I will definitively have to read a documentation on UAC and vista
> security model in general
> to understand how flexible and configurable it is.
> Otherwise, I sure that I will face other side effects.
> 
> Thanks for the tip.
> 
> Arnaud.

Cant we make setup.exe check if its Vista? i mean, its an environment
variable!

UAC does some odd things to user access and permissions.

Just a thought,
Morgan Gangwere

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGXDTDCF9T/dUsmAgRAjLzAJ4y+BAI+Q24nGWlqJ0O+pVRYmURzQCgw5gp
0zDYdR/4XhsATCZWLnmpcT4=
=vZCc
-END PGP SIGNATURE-

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

[ANNOUNCEMENT] Updated [experimental]: tcsh-6.15.00-3

[Corinna Vinschen]

I've uploaded an experimental version 6.15.00-3 of tcsh to cygwin.com.

This version is supposed to solve problems with DOS lineendings when
using tcsh as login shell.  A typical problem are broken or hanging
rsync calls with tcsh as (remote) login shell.

The problem is that Cygwin's tcsh is using textmode on input so far.
This experimental version drops all changes to the underlying mode.
Instead, CR's on input are ignored when reading commands.

I'd like to ask other tcsh users to try this version.  It would be
helpful to get some feedback.

You can distinguish this version from the stable tcsh by its version
string.  -3 adds a "Cygwin-CRLF-test-01" string to the capabilites.

  tcsh-6.15.00-2:

$ echo $version
tcsh 6.15.00 (Astron) 2007-03-03 (i386-intel-posix) options 
8b,nls,dl,al,kan,rh,color,dspm

  tcsh-6.15.00-3:

$ echo $version
tcsh 6.15.00 (Astron) 2007-03-03 (i386-intel-posix) options 
8b,nls,dl,al,kan,rh,color,dspm,Cygwin-CRLF-test-01

If this change doesn't break too much, I'll send the patch upstream
and this change will go into the stable release.


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.  Save it and run setup, answer the questions, then look for
'tcsh' in the 'Shells' category.  Since this is an experimental release,
you will need to use the 'Exp' radio button.


If you have general questions or comments, please send them to the
Cygwin mailing list at: "cygwin at cygwin dot com".  I would appreciate
it if you would use this mailing list rather than emailing me directly.

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

[EMAIL PROTECTED]

If you need more information on unsubscribing, start reading here:

http://sources.redhat.com/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that is available
starting at this URL.

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  cygwin AT cygwin DOT com
Red Hat

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: file permissions on vista

[Larry Hall (Cygwin)]

Arnaud Legout wrote:
> Hello Brian,
> 
> Brian Dessent wrote:
>> I can't reproduce this.  I right click and create a new Notepad file
>> foo.txt, it has the permissions:
>>   
> 
> may be you have deactivated the UAC as morgan suggested?
>> The permissions on a file created with native Windows methods should
>> inherit from the parent folder, following standard NTFS rules, so maybe
>> you need to look at what the containing folder's permissions are set to.
>>   
> 
> I see. Indeed, the access right on the \cygwin\c was 000, then I did a
> chmod u+rwx on this folder,
> but of course, vista is not aware of that and I suppose that NTFS still
> consider that c has no right,
> thus any folder and file created in c:.
> However, I have no idea how to manage those rights on vista.
> Do you know any reasonable documentation on those access rights on vista.
> Also, how are mapped the vista rights to the cygwin rights?




'chmod' manipulates the Windows security mechanism.  The "typical" way of
manipulating permissions from Windows is to use the "Security" tab in the
properties dialog that you can get on any file/folder in the Explorer by
doing a RMB and selecting "Properties".


-- 
Larry Hall  http://www.rfk.com
RFK Partners, Inc.  (508) 893-9779 - RFK Office
216 Dalton Rd.  (508) 893-9889 - FAX
Holliston, MA 01746

_

A: Yes.
> Q: Are you sure?
>> A: Because it reverses the logical flow of conversation.
>>> Q: Why is top posting annoying in email?

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

freetype update?

[Jan Nieuwenhuizen]

Hi,

Can we have a freetype update, LilyPond 2.12 will require at least
2.1.10?

Greetings,
Jan.

-- 
Jan Nieuwenhuizen <[EMAIL PROTECTED]> | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien   | http://www.lilypond.org

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: rsync problems with snapshots

[morgan gangwere]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Corinna Vinschen wrote:
> On May 29 15:21, Angelo Graziosi wrote:
>> Corinna Vinschen wrote:
>>
>>> Any chance that you start debugging this?
>>
>> Sorry, but I have not a great experience with debugging, so when I detect
>> some problems I flag them to the list hoping that someone more expert look
>> at them.
> 
> Maybe this is a good chance to gain some debugging skills?
> 
> 
> Corinna
> 

hmm... what is the command you are trying to run on rsync?
is there an rsync server with the same version on the other end?
can you loop your rsync? (say mirror /home/dookie/source/ to
/home/dookie/dest/)

Just a Thought
Morgan Gangwere
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGXDiaCF9T/dUsmAgRAo9XAJsGnA0iVJJMvV2OemT/od/ZfVrWcQCeN76X
boi2RoKKkgRjTh8fDqF5low=
=AhlD
-END PGP SIGNATURE-

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: [Spam?]Re: problem concating (>>) to a large file

[Eric Blake]

Peter Milne  netspeed.com.au> writes:

> 
> Hi Eric
> 
> Were you able to reproduce the problem I encountered with dd?

Yes - and it looks like there is indeed a cygwin bug, unrelated to my newlib 
patch to stdout.

$ cd /tmp
$ dd bs=1 seek=4540030013 if=/dev/zero of=huge count=1
$ ls -l huge blah
-rw-r--r-- 1 eblake Domain Users 15 May 29 08:27 blah
-rw-r--r-- 1 eblake Domain Users 4540030014 May 29 08:21 huge
$ cat foo.c
#include 
#include 
#include 
#include 

int main (int argc, char **argv)
{
   fprintf (stderr, "%lld\n", lseek (1, 0, SEEK_CUR));
   fprintf (stderr, "%x\n", fcntl (1, F_GETFL));
   return 0;
}
$ ./foo >> blah1
15
110209
$ ./foo >> huge
0
110209

Somehow, when the file size is huge, cygwin is not properly propogating that an 
O_APPEND bit (0x9 in the flags printed from F_GETFL) means that the initial 
offset of fd 1 is the end of the file.  (And it would be nice if strace would 
show the initial lseek offset of all inherited fd's when spawning a process).

You ALSO pointed out a bug in cat - it is calling freopen(NULL, "wb", stdout), 
which effectively wipes out whether stdout was previously in append mode; this 
is an upstream bug, but it only affects cygwin and other platforms where "wb" 
makes a difference.  I'll see about rolling out coreutils-6.9-3 that works 
around it, while posting a patch upstream to fix it.  For small files, you got 
lucky - even though the append mode was lost, the file position was already at 
the end of the file, and since cat doesn't seek, the output went to the right 
location.  But for large files, because of the cygwin bug where the file offset 
is wrong, the output is written to the wrong offset, even WITH the newlib 
stdout patch.

Three bugs in three different source repositories via one problem report (one 
in newlib, already fixed; one in cygwin, and one in coreutils)!  That's gotta 
be some sort of record.

-- 
Eric Blake
volunteer cygwin coreutils maintainer



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: rsync problems with snapshots

[Angelo Graziosi]

Corinna Vinschen wrote:

> Maybe this is a good chance to gain some debugging skills?


May you suggest how to start ?


TIA,

  Angelo.


(I forgot to write that 

rsync -av --delete ftp.dante.de::CTAN/systems/win32/miktex /tmp

works fine with 1.5.24-2 and 1.5.24-2 rebuilt with recent newlib)


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: echo with no line feed

[Igor Peshansky]

On Sat, 26 May 2007, John wrote:

> I can't get:
>
> #! /bin/sh
> echo "Type file name: \c"
> read FNAME
> echo $FNAME
> #
>
> to work without the line feed (using " or ' quotes
> in the echo). Any tips?

'\c' is an escape sequence that prompts 'echo' to disable the trailing
newline.  However, you have to tell 'echo' to look for escape sequences,
i.e.,

echo -e "Type file name: \c"

(quotes don't matter).  Alternatively, as Isaac said, both '/bin/echo' and
the bash 'echo' builtin support the '-n' option to avoid the trailing
newline, i.e.,

echo -n "Type file name: "

(in which case you won't need the '\c').
HTH,
Igor
-- 
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED] | [EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_Igor Peshansky, Ph.D. (name changed!)
 |,4-  ) )-,_. ,\ (  `'-'   old name: Igor Pechtchanski
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

Freedom is just another word for "nothing left to lose"...  -- Janis Joplin

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: [Spam?]Re: problem concating (>>) to a large file

[Eric Blake]

Eric Blake  byu.net> writes:

> Somehow, when the file size is huge, cygwin is not properly propogating that 
an 
> O_APPEND bit (0x9 in the flags printed from F_GETFL) means that the initial 
> offset of fd 1 is the end of the file.  (And it would be nice if strace would 
> show the initial lseek offset of all inherited fd's when spawning a process).

Actually, there is another cygwin bug.  POSIX requires that this assertion 
succeed:

assert (0 == lseek (open("existing", O_WRONLY | O_APPEND), 0, SEEK_CUR));

which is currently not the case on small files.  The file position is only 
moved as part of the subsequent write()s.

-- 
Eric Blake




--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: problem concating (>>) to a large file

[Brian Ford]

On Sat, 26 May 2007, Eric Blake wrote:

> But in classic open source mindset, the release will be sooner if you
> help.

Only microscopically in this case, since to my knowledge there is no
public list of release criteria or open issues that need addressing before
releasing 1.7.0.

-- 
Brian Ford
Lead Realtime Software Engineer
VITAL - Visual Simulation Systems
FlightSafety International
the best safety device in any aircraft is a well-trained crew...

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Slightly off-topic, but...

[Eric Lilja]

Hi, I've installed qt-win-opensource-4.2.3-mingw.exe from trolltech and 
I'm using the tools installed by cygwin to develop Qt programs. Well, 
one could argue I'm not really using cygwin because I have to pass 
-mno-cygwin when compiling otherwise I get errors for non-trivial programs.
Anyway, -mno-cygwin makes the executables dependent on mingwm10.dll 
instead of cygwin1.dll, correct? Since my QT programs depend on this dll 
I can only start them from a cygwin shell since cygwin itself is not in 
windows path (and I don't think it should be).
My question is how safe is it to put mingwm10.dll in the windows path so 
I can start my qt programs from explorer? That would mean having two 
copies of the same dll in the path under cygwin...which I know is bad 
for cygwin1.dll. I was thinking of writing a startup script that checks 
that the files are identical so I know when I need to update the copy. I 
also tried to put a shortcut to the dll but that didn't work which was 
very unfortunate I think.


Any comments welcome...sorry for being off-topic, but maybe this is of 
interest to people using cygwin and maybe want to develop Qt programs 
and don't have a real mingw installation (I don't).


- Eric

PS. I know -mno-cygwin is probably going to be removed in a future 
version of cygwin's compiler, does that mean I would have to maintain a 
real mingw installation to develop Qt programs? I have MSVC++ as well, 
but I believe the Qt version for MSVC++ costs money. Maybe I will buy 
that later when I really need a debugger I can wrap my head around, heh. DS.



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: [Spam?]Re: problem concating (>>) to a large file

[Corinna Vinschen]

On May 29 15:28, Eric Blake wrote:
> Eric Blake  byu.net> writes:
> 
> > Somehow, when the file size is huge, cygwin is not properly propogating 
> > that 
> an 
> > O_APPEND bit (0x9 in the flags printed from F_GETFL) means that the initial 
> > offset of fd 1 is the end of the file.  (And it would be nice if strace 
> > would 
> > show the initial lseek offset of all inherited fd's when spawning a 
> > process).
> 
> Actually, there is another cygwin bug.  POSIX requires that this assertion 
> succeed:
> 
> assert (0 == lseek (open("existing", O_WRONLY | O_APPEND), 0, SEEK_CUR));

Can you give me a pointer?


Thanks,
Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  cygwin AT cygwin DOT com
Red Hat

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Slightly off-topic, but...

[morgan gangwere]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Eric Lilja wrote:
> Hi, I've installed qt-win-opensource-4.2.3-mingw.exe from trolltech and
> I'm using the tools installed by cygwin to develop Qt programs. Well,
> one could argue I'm not really using cygwin because I have to pass
> -mno-cygwin when compiling otherwise I get errors for non-trivial programs.
> Anyway, -mno-cygwin makes the executables dependent on mingwm10.dll
> instead of cygwin1.dll, correct? Since my QT programs depend on this dll
> I can only start them from a cygwin shell since cygwin itself is not in
> windows path (and I don't think it should be).
> My question is how safe is it to put mingwm10.dll in the windows path so
> I can start my qt programs from explorer? That would mean having two
> copies of the same dll in the path under cygwin...which I know is bad
> for cygwin1.dll. I was thinking of writing a startup script that checks
> that the files are identical so I know when I need to update the copy. I
> also tried to put a shortcut to the dll but that didn't work which was
> very unfortunate I think.
> 
> Any comments welcome...sorry for being off-topic, but maybe this is of
> interest to people using cygwin and maybe want to develop Qt programs
> and don't have a real mingw installation (I don't).
> 
> - Eric
> 
> PS. I know -mno-cygwin is probably going to be removed in a future
> version of cygwin's compiler, does that mean I would have to maintain a
> real mingw installation to develop Qt programs? I have MSVC++ as well,
> but I believe the Qt version for MSVC++ costs money. Maybe I will buy
> that later when I really need a debugger I can wrap my head around, heh.
> DS.
> 
> 
> -- 
> Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
> Problem reports:   http://cygwin.com/problems.html
> Documentation: http://cygwin.com/docs.html
> FAQ:   http://cygwin.com/faq/
> 
> 

easy way:
1 - compile as normal
2 - after qmake finishes, COPY cygwin1.dll mingwm10.dll and qtui.dll (or
someshizzat like that) to the OUTPUT directory of your build. now you
can run all this from just doulble clicking it in Windows.

- --
Just a Thought
Morgan Gangwere

For those who want my PGP key:
http://pengunassasin.kicks-ass.org/pgpKey.html

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGXEwUCF9T/dUsmAgRAoqjAKDFU9bKmsHBxsmNCqY6ZCRGcVep8gCfZzp/
933gSQKqTK+Ft73ODj5PrsQ=
=64Aa
-END PGP SIGNATURE-

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

RE: Slightly off-topic, but...

[Dave Korn]

On 29 May 2007 16:52, morgan gangwere wrote:

> easy way:
> 1 - compile as normal
> 2 - after qmake finishes, COPY cygwin1.dll mingwm10.dll and qtui.dll (or
> someshizzat like that) to the OUTPUT directory of your build. now you
> can run all this from just doulble clicking it in Windows.

  Wrong, and bad advice too.  Please don't recommend people go placing
multiple copies of cygwin1.dll on their system, it's a source of massive
problems.

  It's also utterly unnecessary considering the compiled program doesn't need
cygwin1.dll as it is not in any sense a cygwin program.


cheers,
  DaveK
-- 
Can't think of a witty .sigline today


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: [Spam?]Re: problem concating (>>) to a large file

[Eric Blake]

Corinna Vinschen  cygwin.com> writes:

> > 
> > assert (0 == lseek (open("existing", O_WRONLY | O_APPEND), 0, SEEK_CUR));
> 
> Can you give me a pointer?

http://www.opengroup.org/onlinepubs/009695399/functions/open.html
"The file offset used to mark the current position within the file shall be set 
to the beginning of the file."

This is stated prior to any mention of O_APPEND, and O_APPEND does not change 
that statement.  And for O_APPEND|O_RDWR, it is a necessity.

Later, in http://www.opengroup.org/onlinepubs/009695399/functions/write.html:
"If the O_APPEND flag of the file status flags is set, the file offset shall be 
set to the end of the file prior to each write and no intervening file 
modification operation shall occur between changing the file offset and the 
write operation."

so:

int fd = open("existing", O_WRONLY | O_APPEND);
assert (0 == lseek (fd, 0, SEEK_CUR);
if (write (fd, " ", 1) > 0)
  {
assert (0 != lseek (fd, 0, SEEK_CUR));
assert (lseek (fd, 0, SEEK_CUR) == lseek (fd, 0, SEEK_END));
  }

-- 
Eric Blake



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

RE: Slightly off-topic, but...

[Dave Korn]

  Sigh.  This post is a fine example of exactly why we're removing the
-mno-cygwin option: for some reason, despite it being very plainly called "no
cygwin", people just refuse to believe that the stuff it creates has NO CYGWIN
in it.

On 29 May 2007 16:46, Eric Lilja wrote:

> Hi, I've installed qt-win-opensource-4.2.3-mingw.exe 

  More than just 'slightly' off-topic then...

> from trolltech and
> I'm using the tools installed by cygwin to develop Qt programs. Well,
> one could argue I'm not really using cygwin because I have to pass
> -mno-cygwin when compiling otherwise I get errors for non-trivial programs.

  You're not using cygwin.  This isn't arguable, it is a non-negotiable fact
of reality.

> Anyway, -mno-cygwin makes the executables dependent on mingwm10.dll
> instead of cygwin1.dll, correct?

  It invokes a mingw cross-compiler and makes your executables MinGW
executables rather than cygwin executables.

  As such, anything they may or may not do is no more relevant here than any
other non-cygwin application such as Word, Excel or Outlook.

  ObTopic:  You can still use 'cygcheck ' to list the dll
dependencies of the executable.

>  Since my QT programs depend on this dll
> I can only start them from a cygwin shell since cygwin itself is not in
> windows path (and I don't think it should be).

  No, they don't need cygwin anywhere, because they are no-cygwin programs,
which means NO CYGWIN.  You would be better off starting them from a DOS
shell, because they might get confused (as all native win32 apps do) if you
were to try launching them from a cygwin shell connected to a unix pty instead
of having their stdin/out/err connected to a win32 console.

  Incidentally, /why/ do you think cygwin shouldn't be in the path?  I always
put it in my win32 path so that I can use things like grep from a DOS shell.

> My question is how safe is it to put mingwm10.dll in the windows path so
> I can start my qt programs from explorer?

  You'd probably be best off to put the dll and the executable in the same
installation directory.  LoadLibrary always looks in the same dir as the
executable for dlls.  Still, you should be entirely safe putting the mingw
dlls in the PATH.

> That would mean having two
> copies of the same dll in the path under cygwin...which I know is bad
> for cygwin1.dll.

  Which is still completely irrelevant to this completely off-topic post.
But, yes, it's a bad idea, so don't do it.

> Any comments welcome...sorry for being off-topic, but maybe this is of
> interest to people using cygwin and maybe want to develop Qt programs
> and don't have a real mingw installation (I don't).

  No, there's a mingw mailing list for people who want to develop mingw
programs.  The fact of using a cygwin crosscompiler to build it is no more
relevant than whether you used a cygwin or windows text editor to edit the .C
files.

> PS. I know -mno-cygwin is probably going to be removed in a future
> version of cygwin's compiler, does that mean I would have to maintain a
> real mingw installation to develop Qt programs?

  The plan is to replace it with a real mingw cross-compiler as an optional
package, (and keep the mingw runtime and libs packages, but probably relocate
them into a different part of the cygwin directory tree).  You'll need to
learn to say "i686-pc-mingw-gcc" instead of "gcc -mno-cygwin".

  Remember:  "no-cygwin" means NO CYGWIN.

cheers,
  DaveK
-- 
Can't think of a witty .sigline today


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

RE: Slightly off-topic, but...

[Mark Moriarty]

Eric Lilja wrote:
> Hi, I've installed qt-win-opensource-4.2.3-mingw.exe from trolltech 
> and I'm using the tools installed by cygwin to develop Qt programs. 
> Well, one could argue I'm not really using cygwin because I have to 
> pass -mno-cygwin when compiling otherwise I get errors for non-trivial
programs.
> Anyway, -mno-cygwin makes the executables dependent on mingwm10.dll 
> instead of cygwin1.dll, correct? Since my QT programs depend on this 
> dll I can only start them from a cygwin shell since cygwin itself is 
> not in windows path (and I don't think it should be).
> My question is how safe is it to put mingwm10.dll in the windows path 
> so I can start my qt programs from explorer? That would mean having 
> two copies of the same dll in the path under cygwin...which I know is 
> bad for cygwin1.dll. I was thinking of writing a startup script that 
> checks that the files are identical so I know when I need to update 
> the copy. I also tried to put a shortcut to the dll but that didn't 
> work which was very unfortunate I think.
> 
> Any comments welcome...sorry for being off-topic, but maybe this is of 
> interest to people using cygwin and maybe want to develop Qt programs 
> and don't have a real mingw installation (I don't).
> 
> - Eric
> 
> PS. I know -mno-cygwin is probably going to be removed in a future 
> version of cygwin's compiler, does that mean I would have to maintain 
> a real mingw installation to develop Qt programs? I have MSVC++ as 
> well, but I believe the Qt version for MSVC++ costs money. Maybe I 
> will buy that later when I really need a debugger I can wrap my head
around, heh.
> DS.
> 
> 
> -- 
> Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
> Problem reports:   http://cygwin.com/problems.html
> Documentation: http://cygwin.com/docs.html
> FAQ:   http://cygwin.com/faq/
> 
> 

easy way:
1 - compile as normal
2 - after qmake finishes, COPY cygwin1.dll mingwm10.dll and qtui.dll (or
someshizzat like that) to the OUTPUT directory of your build. now you can
run all this from just doulble clicking it in Windows.

- --
Just a Thought
Morgan Gangwere

--
It probably depends on what you're actually trying to do/build.  I use
Cygwin as my environment to build VLC (a cross-platform video package).  VLC
is adding a QT4-based GUI.  The output file set (a lot of DLLs, plus the
main executable) does not require any Cygwin or Mingw DLL to run.


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: [Spam?]Re: problem concating (>>) to a large file

[Corinna Vinschen]

On May 29 15:28, Eric Blake wrote:
> Eric Blake  byu.net> writes:
> 
> > Somehow, when the file size is huge, cygwin is not properly propogating 
> > that 
> an 
> > O_APPEND bit (0x9 in the flags printed from F_GETFL) means that the initial 
> > offset of fd 1 is the end of the file.  (And it would be nice if strace 
> > would 
> > show the initial lseek offset of all inherited fd's when spawning a 
> > process).
> 
> Actually, there is another cygwin bug.  POSIX requires that this assertion 
> succeed:
> 
> assert (0 == lseek (open("existing", O_WRONLY | O_APPEND), 0, SEEK_CUR));
> 
> which is currently not the case on small files.  The file position is only 
> moved as part of the subsequent write()s.

I fixed both bugs in CVS.  It's rather disappointing that

  SetFilePointer (handle, 0, NULL, FILE_END);

fails for files > 4Gigs.  It's actually required that the offset_high
pointer is a valid pointer to a LONG containing 0.  Oh well.

Thanks for the report and the testcase.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  cygwin AT cygwin DOT com
Red Hat

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Slightly off-topic, but...

[morgan gangwere]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Dave Korn wrote:
> On 29 May 2007 16:52, morgan gangwere wrote:
> 
>> easy way:
>> 1 - compile as normal
>> 2 - after qmake finishes, COPY cygwin1.dll mingwm10.dll and qtui.dll (or
>> someshizzat like that) to the OUTPUT directory of your build. now you
>> can run all this from just doulble clicking it in Windows.
> 
>   Wrong, and bad advice too.  Please don't recommend people go placing
> multiple copies of cygwin1.dll on their system, it's a source of massive
> problems.

right then i was mistaken.

>   It's also utterly unnecessary considering the compiled program doesn't need
> cygwin1.dll as it is not in any sense a cygwin program.
> 

ok then I was really mistaken

> cheers,
>   DaveK

thanks for correcting me daveK

- --
Just a Thought
Morgan Gangwere

For those who want my PGP key:
http://pengunassasin.kicks-ass.org/pgpKey.html

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGXGjLCF9T/dUsmAgRAuX+AKC9MadecaT0Xf/dPLW7zkkRyG9afQCfbBnf
iJh2n7nlK09z9bFc7fTg6ZE=
=uQpl
-END PGP SIGNATURE-

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Slightly off-topic, but...

[Brian Dessent]

Eric Lilja wrote:

> Hi, I've installed qt-win-opensource-4.2.3-mingw.exe from trolltech and
> I'm using the tools installed by cygwin to develop Qt programs. Well,
> one could argue I'm not really using cygwin because I have to pass
> -mno-cygwin when compiling otherwise I get errors for non-trivial programs.

Yes, this question should really be to the MinGW list.

> Anyway, -mno-cygwin makes the executables dependent on mingwm10.dll
> instead of cygwin1.dll, correct? Since my QT programs depend on this dll

mingwm10.dll is a small stub DLL used to free TLS allocations when a
thread is destroyed, preventing a memory leak.  That is all it does; the
only reason it is a DLL and not statically linked in as part of the
runtime like all other parts of MinGW is because it must be a DLL so
that it can have a DllMain that gets called on THREAD_DETACH.  And note
that you only get this dependency on this DLL if you use -mthreads,
which is a requirement if you want thread-safe exception handling.

> I can only start them from a cygwin shell since cygwin itself is not in
> windows path (and I don't think it should be).

I see what you're saying (that Cygwin puts mingwm10.dll in /usr/bin as
part of the mingw-runtime package), but really Cygwin is totally
irrelevant here.  The only thing that matters is mingwm10.dll, which you
can easily copy anywhere without worry, since this file does essentially
one tiny minor task and is very different than cygwin1.dll that contains
the entire Cygwin runtime support code.

> My question is how safe is it to put mingwm10.dll in the windows path so
> I can start my qt programs from explorer? That would mean having two
> copies of the same dll in the path under cygwin...which I know is bad
> for cygwin1.dll. I was thinking of writing a startup script that checks
> that the files are identical so I know when I need to update the copy. I
> also tried to put a shortcut to the dll but that didn't work which was
> very unfortunate I think.

It should be fine.  mingwm10.dll doesn't change often or even at all,
and I suspect if there was a major change the '10' would be bumped to
differentiate it from the previous version.

Brian

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

[ANNOUNCEMENT] [ANNOUNCEMENT] New package: ddrescue-1.3-1

[Christian Franke]

The GNU ddrescue package is now part of the Cygwin distribution.

http://www.gnu.org/software/ddrescue/ddrescue.html


Important note for Cygwin (<= 1.5.24-2):

When reading from a raw device with sector size > 512 Bytes, it is
required to specify the exact sector size with the '-b' option.
(for CD/DVD e.g: ddrescue -b 2048 /dev/scd0 cd.iso cd.log)
Otherwise, ddrescue may crash due to a bug in Cygwin's raw device
lseek(). The bug is fixed in Cygwin snapshot 2007-05-23 or later.


Description of ddrescue from README:

GNU ddrescue is a data recovery tool. It copies data from one file or
block device (hard disc, cdrom, etc) to another, trying hard to rescue
data in case of read errors.

Ddrescue does not truncate the output file if not asked to. So, every
time you run it on the same output file, it tries to fill in the gaps.

The basic operation of ddrescue is fully automatic. That is, you don't
have to wait for an error, stop the program, read the log, run it in
reverse mode, etc.

If you use the logfile feature of ddrescue, the data is rescued very
efficiently (only the needed blocks are read). Also you can interrupt
the rescue at any time and resume it later at the same point.

Automatic merging of backups: If you have two or more damaged copies of
a file, cdrom, etc, and run ddrescue on all of them, one at a time,
with the same output file, you will probably obtain a complete and
error-free file. This is so because the probability of having damaged
areas at the same places on different input files is very low. Using
the logfile, only the needed blocks are read from the second and
successive copies.

The logfile is periodically saved to disc. So in case of a crash you can
resume the rescue with little recopying.

Also, the same logfile can be used for multiple commands that copy
different areas of the file, and for multiple recovery attempts over
different subsets.

Ddrescue aligns its I/O buffer to the sector size so that it can be used
to read from raw devices. For efficiency reasons, also aligns it to the
memory page size if page size is a multiple of sector size. Read the
info file to learn how to use raw devices with ddrescue.



Christian Franke

--

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 keep clicking "Next".

If you have questions or comments, please send them to the Cygwin
mailing list.

 *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list, please
use the automated form at:

http://cygwin.com/lists.html#subscribe-unsubscribe

If this does not work, then 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:

[EMAIL PROTECTED]

If you need more information on unsubscribing, start reading here:

http://sourceware.org/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that is available
starting at this URL.


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: [Spam?]Re: problem concating (>>) to a large file

[Eric Blake]

Corinna Vinschen  cygwin.com> writes:

> I fixed both bugs in CVS.  It's rather disappointing that
> 
>   SetFilePointer (handle, 0, NULL, FILE_END);
> 
> fails for files > 4Gigs.  It's actually required that the offset_high
> pointer is a valid pointer to a LONG containing 0.  Oh well.

Nice catch; I was trying to spot it myself, and it is crystal clear now that I 
go reread the msdn page on SetFilePointer, but I wasn't seeing it on my own.  
At least it was twice as generous as ftell/fseek failing on files > 2GB - 1 
byte.

Shoot - now that means I have to fix coreutils ASAP so that the trivial 'cat 
smallfile >> smallfile' will once again work for snapshot users, now that you 
correctly took away the non-POSIX seek in exec()!  Thanks for the quick 
turnaround on fixing the cygwin side of this, and for the OP's persistence.  
And thank goodness for sparse files in NTFS (as I don't really have 4 gig of 
disk space available in my /tmp).

-- 
Eric Blake



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Build problems - unistd.h

[Scott Peterson]

Eric, when I try make CC="gcc -E" I get this error in the output:
.libs/dbus-glib.o: file not recognized: File format not recognized


I'm building dbus-glib from source and I get this error when I make:

In file included from /usr/include/unistd.h:4,
from dbus-binding-tool-glib.c:39:
/usr/include/sys/unistd.h:108: error: parse error before numeric constant

Ideas?


Use gcc -E to look at the preprocessed source, and see what namespace
collision was caused somewhere in lines 1-38 of dbus-binding-tool-glib.c
that caused the syntax error?


--
Scott.

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Build problems - unistd.h

[Brian Dessent]

Scott Peterson wrote:

> Eric, when I try make CC="gcc -E" I get this error in the output:
> .libs/dbus-glib.o: file not recognized: File format not recognized

You just created an .o file consisting of the output of the
preprocessor.  That's obviously not going to work in the context of make
where the build continues.  If you're going to use -E you need to run
the command by hand outside of make and change the output filename to
something like filename.i, or any filename you want really, as long as
you aren't trying to overwrite a file with something in an unrelated
format.  Or alternatively, you can use -save-temps which unlike -E still
compiles the file normally, but leaves the intermediate forms
(preprocessed source and assembly) which are normally unlinked.

Brian

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

howto use ramdrive to speed-up cygwin

[Hans Horn]

Group,

Could somebody give me a few pointers as to how to use/configure a 
ramdrive to speed-up cygwin.


There was a posting a few weeks ago 
(http://sourceware.org/ml/cygwin/2007-05/msg00121.html) in which Brian 
Dessent mentions that he is using a ramdrive for building gcc.


Brian, would you mind disclosing a few more details about this?

thx a bunch,
H.


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: echo with no line feed

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Igor Peshansky on 5/29/2007 9:20 AM:
> '\c' is an escape sequence that prompts 'echo' to disable the trailing
> newline.  However, you have to tell 'echo' to look for escape sequences,
> i.e.,
> 
> echo -e "Type file name: \c"

Except that POSIX states that echo takes no options, so you are invoking
inherently non-portable behavior.  Better would be using printf(1) instead
of echo(1).

- --
Don't work too hard, make some time for fun as well!

Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGXL6y84KuGfSFAYARApKrAKCCZjbrs7mlw2tgrH1V4dkIyZyk+gCeISjz
9ean3u69W92ONVPYvAY6RJ4=
=vzbd
-END PGP SIGNATURE-

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: howto use ramdrive to speed-up cygwin

[Brian Dessent]

Hans Horn wrote:

> Could somebody give me a few pointers as to how to use/configure a
> ramdrive to speed-up cygwin.
> 
> There was a posting a few weeks ago
> (http://sourceware.org/ml/cygwin/2007-05/msg00121.html) in which Brian
> Dessent mentions that he is using a ramdrive for building gcc.
> 
> Brian, would you mind disclosing a few more details about this?

There's nothing really that exciting about what I did, it was mainly for
running the gcc testsuite that I was experimenting with ways to make the
time pass faster.  I noticed from both the HD light and from
sysinternals' FileMon that there was constant reading/seeking of the
xgcc under test, so I put the whole build directory on a ramdisk.

Obviously, you want to compress the ramdisk and you also have to either
have a lot of RAM or not build all languages.  Ada and Java in
particular will kill you, as they generate a ton of temporary binaries
when running the testsuite, and these all have full debug info by
default.  A full three stage bootstrap of all languages plus running the
testsuite currently occupies 7.45 GB in my build dir, so obviously you
have to do some paring down if you want to fit that all.  I can't
remember if I also moved /usr/bin onto the ramdrive or not.  I think I
did with a stripped down /usr/bin from a minimal install.  The mount
command makes it easy to relocate dirs physically but leave them in the
same location in the posix filespace.

You can also play around with removing -g from TARGET_CFLAGS and
"bootstrap-lean" to save space, but I don't remember if those helped or
not.  I remember getting a little frustrated that there were so many
different CFLAGS to specify and I was never able to get them all so as
to have the result be no bloating debug info.  Off the top of my head
there's something like:

BOOT_*FLAGS - for the stage 1 bootstrap
STAGE_*FLAGS - for stage 2, 3
TARGET_*FLAGS - for the target libraries

...And then I think there's a few more nonstandard ones for the Ada
runtime and perhaps a couple more that I missed.  Alternatively there's
always LDFLAGS="-s" which might have been easier.  Anyway, getting back
on topic.

This is not a general purpose solution to speeding Cygwin up, it was
just for the particular purpose of running the testsuite, which current
takes for-frickin-ever because of whatever it is that dejagnu does that
causes every single spawn of a test to hit the disk.  You would think
the Windows system disk cache would kick in and prevent having to do
this sillyness, but it never did; the HD light never went out despite
spawning the same binaries over and over again time after time.

Brian

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Build problems - unistd.h

[Brian Dessent]

Scott Peterson wrote:

> Here's the content of the intermediate file dbus-binding-tool-glib.i:

Did you really have to send a 350 KB message to thousands of people? 
Some people consider that a little wasteful when exactly one line of all
of that was relevant.  If you're going to do that at least send it as a
compressed attachment.

Line 108 of unistd.h after preprocessing is:

int __attribute__((__cdecl__)) _pipe (int __fildes[2], 4096, _O_BINARY);

That is obviously wrong, it's not even a valid function prototype any
more, not to mention the underscore and the fact that pipe only takes
one argument.  It should look more like:

$ gcc -E /usr/include/sys/unistd.h | grep pipe
int __attribute__((__cdecl__)) pipe (int __fildes[2] );

So, you'll need to look through all the headers that are included before
that point and find out where this erroneous macro expansion is coming
from.

Brian

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Build problems - unistd.h

[Greg Chicares]

On 2007-05-30 00:12Z, Scott Peterson wrote:
> 
> Here's the content of the intermediate file dbus-binding-tool-glib.i:

[major snip]

On 2007-05-29 02:07Z, you had written:
>
> In file included from /usr/include/unistd.h:4,
> from dbus-binding-tool-glib.c:39:
> /usr/include/sys/unistd.h:108: error: parse error before numeric constant

Look at line 108 of that file. In my copy, it's a prototype
for _pipe() . Now look for _pipe() in the preprocessed output:

> int __attribute__((__cdecl__)) _pipe (int __fildes[2], 4096, _O_BINARY);

Maybe that's the "parse error before numeric constant"?

What does line 108 in your /usr/include/sys/unistd.h say,
exactly? Assuming it's not corrupted, the real question is
how it got turned into the preprocessed line above.

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Build problems - unistd.h

[Matthew Woehlke]

Greg Chicares wrote:

On 2007-05-30 00:12Z, Scott Peterson wrote:

Here's the content of the intermediate file dbus-binding-tool-glib.i:


[major snip]

On 2007-05-29 02:07Z, you had written:

In file included from /usr/include/unistd.h:4,
from dbus-binding-tool-glib.c:39:
/usr/include/sys/unistd.h:108: error: parse error before numeric constant


Look at line 108 of that file. In my copy, it's a prototype
for _pipe() . Now look for _pipe() in the preprocessed output:


int __attribute__((__cdecl__)) _pipe (int __fildes[2], 4096, _O_BINARY);


Maybe that's the "parse error before numeric constant"?

What does line 108 in your /usr/include/sys/unistd.h say,
exactly? Assuming it's not corrupted, the real question is
how it got turned into the preprocessed line above.


...to hazard a guess, I suspect some .h has '#define pipe(a) _pipe(a, 
4096, _O_BINARY)'.


--
Matthew
"A mouse is a device used to point at the xterm you want to type in."
  --Kim Alm, A.S.R.


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: howto use ramdrive to speed-up cygwin

[Hans Horn]

Brian Dessent wrote:

Hans Horn wrote:


Could somebody give me a few pointers as to how to use/configure a
ramdrive to speed-up cygwin.

There was a posting a few weeks ago
(http://sourceware.org/ml/cygwin/2007-05/msg00121.html) in which Brian
Dessent mentions that he is using a ramdrive for building gcc.

Brian, would you mind disclosing a few more details about this?


There's nothing really that exciting about what I did, it was mainly for
running the gcc testsuite that I was experimenting with ways to make the
time pass faster.  I noticed from both the HD light and from
sysinternals' FileMon that there was constant reading/seeking of the
xgcc under test, so I put the whole build directory on a ramdisk.

Obviously, you want to compress the ramdisk and you also have to either
have a lot of RAM or not build all languages.  Ada and Java in
particular will kill you, as they generate a ton of temporary binaries
when running the testsuite, and these all have full debug info by
default.  A full three stage bootstrap of all languages plus running the
testsuite currently occupies 7.45 GB in my build dir, so obviously you
have to do some paring down if you want to fit that all.  I can't
remember if I also moved /usr/bin onto the ramdrive or not.  I think I
did with a stripped down /usr/bin from a minimal install.  The mount
command makes it easy to relocate dirs physically but leave them in the
same location in the posix filespace.

You can also play around with removing -g from TARGET_CFLAGS and
"bootstrap-lean" to save space, but I don't remember if those helped or
not.  I remember getting a little frustrated that there were so many
different CFLAGS to specify and I was never able to get them all so as
to have the result be no bloating debug info.  Off the top of my head
there's something like:

BOOT_*FLAGS - for the stage 1 bootstrap
STAGE_*FLAGS - for stage 2, 3
TARGET_*FLAGS - for the target libraries

...And then I think there's a few more nonstandard ones for the Ada
runtime and perhaps a couple more that I missed.  Alternatively there's
always LDFLAGS="-s" which might have been easier.  Anyway, getting back
on topic.

This is not a general purpose solution to speeding Cygwin up, it was
just for the particular purpose of running the testsuite, which current
takes for-frickin-ever because of whatever it is that dejagnu does that
causes every single spawn of a test to hit the disk.  You would think
the Windows system disk cache would kick in and prevent having to do
this sillyness, but it never did; the HD light never went out despite
spawning the same binaries over and over again time after time.

Brian



Hi Brian,
thx for responding!

I wasn't aiming for building gcc ! Instead I was rather interested in 
the ramdisk aspect of that particular posting, and how I may be able to 
use the idea to perhaps speedup cygwin in general (speedier compilations 
are of course welcome!).


What ramdisk software did you use? Do you have some sort of automated 
setup that places /bin onto the ramdisk at boot time, and takes care of 
the appropriate mount?

In case my questions sound naiive - well, that's just what they are.
I'm simply trying to find ways to make things go faster.

thx again,
H.


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

more on Re: bash process substitution "<(list)" [spot the difference]

[B. K. Oxley (binkley)]

I am exploring how process substitution works on Cygwin.  I have scripts 
which run fine on Linux but not on Windows XP.


Why does one of these scripts produce an error and the other does not?

Script #1:

$ cat a
#!/bin/bash

function f()
{
   echo "$1"
   cat "$1"
}

f <(echo OK)

$ ./a
/proc/self/fd/63
OK

Script #2:

$ cat b
#!/bin/bash

function f()
{
   ls -l "$1"
   cat "$1"
}

f <(echo OK)

$ ./b
lrwxrwxrwx 1 luser None 0 May 29 15:49 /proc/self/fd/63 -> pipe:[1728]
cat: /proc/self/fd/63: No such file or directory

Thanks,
--binkley
http://binkley.blogspot.com/


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: more on Re: bash process substitution "<(list)" [spot the difference]

[Larry Hall (Cygwin)]

B. K. Oxley (binkley) wrote:
> I am exploring how process substitution works on Cygwin.  I have scripts
> which run fine on Linux but not on Windows XP.
> 
> Why does one of these scripts produce an error and the other does not?
> 
> Script #1:
> 
> $ cat a
> #!/bin/bash
> 
> function f()
> {
>echo "$1"
>cat "$1"
> }
> 
> f <(echo OK)
> 
> $ ./a
> /proc/self/fd/63
> OK
> 
> Script #2:
> 
> $ cat b
> #!/bin/bash
> 
> function f()
> {
>ls -l "$1"
>cat "$1"
> }
> 
> f <(echo OK)
> 
> $ ./b
> lrwxrwxrwx 1 luser None 0 May 29 15:49 /proc/self/fd/63 -> pipe:[1728]
> cat: /proc/self/fd/63: No such file or directory

With the exception of a slight bit of file name conversion, I get the same
result as you do with Cygwin when I run on Linux (FC4):

# /tmp/a
/dev/fd/63
OK

#  /tmp/b
lr-x--  1 lhall lhall 64 May 29 23:26 /dev/fd/63 -> pipe:[916212]
cat: /dev/fd/63: No such file or directory

This is using your scripts verbatim.

-- 
Larry Hall  http://www.rfk.com
RFK Partners, Inc.  (508) 893-9779 - RFK Office
216 Dalton Rd.  (508) 893-9889 - FAX
Holliston, MA 01746

_

A: Yes.
> Q: Are you sure?
>> A: Because it reverses the logical flow of conversation.
>>> Q: Why is top posting annoying in email?

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

[ANNOUNCEMENT] Updated: coreutils-6.9-3

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

A new release of coreutils, 6.9-3, is available, replacing 6.9-2 as current.

NEWS:
=
This is a minor patch release.  It works around upstream bugs discovered
in cat, cksum, head, md5sum, tac, tail, tee, and tr when stdout begins
life in append mode, but which were masked by a cygwin bug that was
present up until the 20070529 snapshot.  See also the upstream
documentation in /usr/share/doc/coreutils-6.9/.

DESCRIPTION:

GNU coreutils provides a collection of commonly used utilities essential
to a standard POSIX environment.  It comprises the former textutils,
sh-utils, and fileutils packages.  The following executables are included:

[ base64 basename cat chgrp chmod chown chroot cksum comm cp csplit cut
date dd df dir dircolors dirname du echo env expand expr factor false fmt
fold gkill groups head hostid hostname id install join link ln logname ls
md5sum mkdir mkfifo mknod mv nice nl nohup od paste pathchk pinky pr
printenv printf ptx pwd readlink rm rmdir seq sha1sum sha224sum sha256sum
sha384sum sha512sum shred shuf sleep sort split stat stty su sum sync tac
tail tee test touch tr true tsort tty uname unexpand uniq unlink users
vdir wc who whoami yes

UPDATE:
===
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.
Save it and run setup, answer the questions, then look for 'coreutils' in
the 'Base' category (it should already be selected).  Since this is an
experimental release, you will need to use the 'Exp' radio button.

DOWNLOAD:
=
Note that downloads from sources.redhat.com (aka cygwin.com) aren't
allowed due to bandwidth limitations.  This means that you will need to
find a mirror which has this update, please choose the one nearest to you:
http://cygwin.com/mirrors.html

QUESTIONS:
==
If you want to make a point or ask a question the Cygwin mailing list is
the appropriate place.

- --
Eric Blake
volunteer cygwin coreutils maintainer

CYGWIN-ANNOUNCE UNSUBSCRIBE INFO:
=
To unsubscribe to 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:

[EMAIL PROTECTED]

If you need more information on unsubscribing, start reading here:

http://sources.redhat.com/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that is available
starting at this URL.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGXO5L84KuGfSFAYARAg3KAKCe2eiFkQS4JHmWUJWS0LZ6YPP6awCfSkBr
Z0B/CXd46DUh3dpIOzYHdek=
=e0Ry
-END PGP SIGNATURE-

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: more on Re: bash process substitution "<(list)" [spot the difference]

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to B. K. Oxley (binkley) on 5/29/2007 9:05 PM:
> Why does one of these scripts produce an error and the other does not?
> function f()
> {
>echo "$1"

shell builtin, and it does not touch the fifo (try replacing this with
/bin/echo to see the difference)

>cat "$1"

so the fifo is still available

> function f()
> {
>ls -l "$1"

external process, which calls exit() and thus closes the only read handle
on the fifo.  At which point, the writer is closed since no reader exists.

>cat "$1"

the fifo no longer exists, so the error is correct

If you need the fifo to persist over several external commands, you need
to use a shell grouping construct or an exec so that the shell holds a
handle to the fifo for the duration of the shell function.  And this is
not cygwin specific.

- --
Don't work too hard, make some time for fun as well!

Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGXPKR84KuGfSFAYARAlZuAKDVNUr7vzs2lRFjcaS0201C+uu7IgCfUK81
vVzTHO2X4g0SKg2CBK126hk=
=UL94
-END PGP SIGNATURE-

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Problem with setup.exe - C:\cygwin\bin\* isn't created

[Jean-Pierre Bogler]

Hello all,

I hope you can help me, I'm really having problems to install cygwin.

My OS is Win2k SP 2. I have downloaded the latest version of setup.exe
(2.510.2.2) and stored it into C:\cyginstall.
I started the installation with administrator rights. Then I went through
the installation choosing:

- Installation from Internet
- C:\cygwin as root path
- Install for all users
- Textfile type: Unix/binary
- Internet Connection: Direct Connection
- A mirror near to me: http://linux.rz.tuhr-uni-bochum.de
- I did not change the package settings and wanted to make a default
installation

The download process worked well an the installation began. After the
installation I decided to add a desktop icon and double clicked on it.
The dos box told me that it can't change the directory und can't find
bash.exe :(, so I looked into the C:\cygwin directory.

The only installed directories are: etc, lib, sbin, usr, var. And the files:
cygwin.bat and cygwin.ico. There is no bin directory!
The setup.log file is full of the complaining listed below (... means that
the message above appears more than once).

I hope you can help me. Many thanks in advance!

Jean-Pierre

2007/05/30 07:09:44 Starting cygwin install, version 2.510.2.2
2007/05/30 07:09:44 io_stream_cygfile: fopen failed 2 No such file or
directory
...
2007/05/30 07:09:44 Current Directory: C:\cyginstall
2007/05/30 07:09:44 Changing gid to Users
2007/05/30 07:09:44 Could not open service McShield for query, start and
stop. McAfee may not be installed, or we don't have access.
2007/05/30 07:09:46 io_stream_cygfile: fopen failed 2 No such file or
directory
...
2007/05/30 07:09:47 source: from cwd
2007/05/30 07:09:48 root: C:\cygwin binary system
2007/05/30 07:09:49 io_stream_cygfile: fopen failed 2 No such file or
directory
...
2007/05/30 07:09:49 Selected local directory: C:\cyginstall
2007/05/30 07:09:49 io_stream_cygfile: fopen failed 2 No such file or
directory

...
2007/05/30 07:09:58 Installing
file://C:\cyginstall/http%3a%2f%2flinux.rz.ruhr-uni-bochum.de%2fdownload%2fc
ygwin/release/alternatives/alternatives-1.3.29a-1.tar.bz2
.(all the packages).
2007/05/30 07:10:55 Visited: 54 nodes out of 116.
2007/05/30 07:10:55 Dependency ordered install:
2007/05/30 07:10:55 alternatives
(packages)..
2007/05/30 07:10:55 running: c:\Dokumente und
Einstellungen\Wohnzimmer\Desktop\PDFMergeW\PDFMerge\bin\\bash.exe -c
/etc/postinstall/00ash.sh
2007/05/30 07:10:57 abnormal exit: exit code=0
2007/05/30 07:10:57 running: c:\Dokumente und
Einstellungen\Wohnzimmer\Desktop\PDFMergeW\PDFMerge\bin\\bash.exe -c
/etc/postinstall/00bash.sh
2007/05/30 07:10:58 abnormal exit: exit code=0
2007/05/30 07:10:58 running: c:\Dokumente und
Einstellungen\Wohnzimmer\Desktop\PDFMergeW\PDFMerge\bin\\bash.exe -c
/etc/postinstall/base-files-mketc.sh
2007/05/30 07:10:59 abnormal exit: exit code=0
2007/05/30 07:10:59 running: c:\Dokumente und
Einstellungen\Wohnzimmer\Desktop\PDFMergeW\PDFMerge\bin\\bash.exe -c
/etc/postinstall/base-files-profile.sh
2007/05/30 07:11:00 abnormal exit: exit code=0
2007/05/30 07:11:00 running: c:\Dokumente und
Einstellungen\Wohnzimmer\Desktop\PDFMergeW\PDFMerge\bin\\bash.exe -c
/etc/postinstall/bzip2.sh
2007/05/30 07:11:00 abnormal exit: exit code=0
2007/05/30 07:11:00 running: c:\Dokumente und
Einstellungen\Wohnzimmer\Desktop\PDFMergeW\PDFMerge\bin\\bash.exe -c
/etc/postinstall/coreutils.sh
2007/05/30 07:11:00 abnormal exit: exit code=0
2007/05/30 07:11:00 running: c:\Dokumente und
Einstellungen\Wohnzimmer\Desktop\PDFMergeW\PDFMerge\bin\\bash.exe -c
/etc/postinstall/cygwin-doc.sh
2007/05/30 07:11:02 abnormal exit: exit code=0
2007/05/30 07:11:02 running: c:\Dokumente und
Einstellungen\Wohnzimmer\Desktop\PDFMergeW\PDFMerge\bin\\bash.exe -c
/etc/postinstall/findutils.sh
2007/05/30 07:11:03 abnormal exit: exit code=0
2007/05/30 07:11:03 running: c:\Dokumente und
Einstellungen\Wohnzimmer\Desktop\PDFMergeW\PDFMerge\bin\\bash.exe -c
/etc/postinstall/libgdbm-devel.sh
2007/05/30 07:11:03 abnormal exit: exit code=0
2007/05/30 07:11:03 running: c:\Dokumente und
Einstellungen\Wohnzimmer\Desktop\PDFMergeW\PDFMerge\bin\\bash.exe -c
/etc/postinstall/man.sh
2007/05/30 07:11:03 abnormal exit: exit code=0
2007/05/30 07:11:03 running: c:\Dokumente und
Einstellungen\Wohnzimmer\Desktop\PDFMergeW\PDFMerge\bin\\bash.exe -c
/etc/postinstall/passwd-grp.sh
2007/05/30 07:11:04 abnormal exit: exit code=0
2007/05/30 07:11:04 running: c:\Dokumente und
Einstellungen\Wohnzimmer\Desktop\PDFMergeW\PDFMerge\bin\\bash.exe -c
/etc/postinstall/tar.sh
2007/05/30 07:11:05 abnormal exit: exit code=0
2007/05/30 07:11:05 running: c:\Dokumente und
Einstellungen\Wohnzimmer\Desktop\PDFMergeW\PDFMerge\bin\\bash.exe -c
/etc/postinstall/terminfo.sh
2007/05/30 07:11:05 abnormal exit: exit code=0
2007/05/30 07:11:05 running: c:\Dokumente