Well, that is some interesting stuff. So, in POSIX, the child gets the
same FD in the same place and it is actually a second reference to the
kernels open file table. The same entry as the parent uses (via FD) to
determine the offset, flags, etc.
That would explain why the child calling exit() flus
On Fri, Jan 17, 2014 at 3:19 PM, Corinna Vinschen wrote:
> Our ipv6 stuff is in cygwin/in6.h, which is included by cygwin/in.h,
> which in turn is included by netinet/in.h.
Ah, that explains it.
> We could fetch FreeBSDs netinet/ip6.h. In contrast to Glibc's
> netinet/ip6.h it does not include n
On Jan 17 16:32, Christopher Faylor wrote:
> On Fri, Jan 17, 2014 at 02:29:45PM -0700, Warren Young wrote:
> >On 1/17/2014 13:45, Aaron Humphrey wrote:
> >>
> >> So why does it think it
> >> requires ip6.h if it compiles fine without it?
> >
> >It's probably an unwarranted Linuxism.
>
> AUL. I li
On 01/17/2014 01:10 PM, Eric Blake wrote:
>> However..
>>
>> Do I understand that to say that if the first thing my child does is
>>
>> fclose(fp);
>>
>> everything should be hunky-dory?
>
> No. You have to fix things _in the parent, before the fork()_ for
> everything to be hunky-dory. The
Looks like vim isn't the only problem here, nor is screen. I was able
to see some other poor behaviour by looking at a man page and then
searching for a string which didn't exist--whether running 'screen' or
not. It displayed "Pattern not found" on the bottom line, which
caused a bunch of lines t
On Fri, Jan 17, 2014 at 02:29:45PM -0700, Warren Young wrote:
>On 1/17/2014 13:45, Aaron Humphrey wrote:
>>
>> So why does it think it
>> requires ip6.h if it compiles fine without it?
>
>It's probably an unwarranted Linuxism.
AUL. I like it.
cgf
--
Problem reports: http://cygwin.com/prob
On 1/17/2014 13:45, Aaron Humphrey wrote:
So why does it think it
requires ip6.h if it compiles fine without it?
It's probably an unwarranted Linuxism. As I read POSIX[*], it is legal
to have IPv6 definitions in the same old headers the IPv4 interface is
defined in, as Cygwin does.
So, th
In message <52d98e1d.8010...@redhat.com>you write:
>
>No. You have to fix things _in the parent, before the fork()_ for
>everything to be hunky-dory. The easiest way to do that is to
>fflush(NULL) before fork()ing.
>
You learn something new every day.
Usually just after you needed to know it.
On Fri, Jan 17, 2014 at 12:34 PM, Warren Young wrote:
> On 1/17/2014 11:58, Aaron Humphrey wrote:
>>
>> I had thought that cygwin 1.7 had IPv6 support,
>
>
> It does, to the extent that the underlying Winsock APIs do. Basically, you
> want to be on Vista or newer if you're going to depend on IPv6
On 01/14/2014 08:50 AM, tedno...@bellsouth.net wrote:
> In message <52d55d96.8070...@redhat.com>you write:
>>
>> Your program may be violating POSIX, which would trigger undefined behavior.
>>
>> Quoting POSIX:
>> pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_05
>>
>
> [
On 01/15/2014 08:28 AM, tedno...@bellsouth.net wrote:
> Well, all I can say in this instance, is that arguably conforming to
> the bare letter of the standard (if that's in fact what is happening)
> is not "the right thing". People certainly don't expect that stdio
> file pointers that exist at f
On 01/14/2014 09:53 PM, Lord Laraby wrote:
> My two cents say, since the child is not referencing 'fp' at all,
> there is no violation of the POSIX semantics in this situation.
But the child _IS_ referencing 'fp', via the implicit fflush(NULL) done
by exit(). If you use _exit() to bypass that imp
On 01/13/2014 09:06 AM, tedno...@bellsouth.net wrote:
> while( fgets(buf, sizeof(buf), fp) ) {
> ++i;
>
> if(sscanf(buf, "%s %s", infile, outfile) != 2) {
>
> switch (fork()) {
>
> case 0:
>
On 1/17/2014 11:58, Aaron Humphrey wrote:
I had thought that cygwin 1.7 had IPv6 support,
It does, to the extent that the underlying Winsock APIs do. Basically,
you want to be on Vista or newer if you're going to depend on IPv6 under
Cygwin. IPv6 support for earlier versions of Windows was
Greetings, Corinna Vinschen!
> Interesting, I always thought --enable-imap is default in mutt.
I think you're confused here.
IMAP is the mail delivery protocol. Used by mail user agents to access your
mailbox, similarly with POP3.
SMTP is the mail submission and transfer protocol used to submi
On Fri, Jan 17, 2014 at 12:45:47PM -0500, Jason Tishler wrote:
>On Fri, Jan 17, 2014 at 11:30:54AM -0500, David Boyce wrote:
>If you wrap rebaseall in its entirety and retry on failure until
>successful, then that will eliminate the "race condition" issue.
>
>If consensus thinks this change is gene
David,
On Fri, Jan 17, 2014 at 11:30:54AM -0500, David Boyce wrote:
> On Fri, Jan 17, 2014 at 11:13 AM, Jason Tishler wrote:
> > AFAICT, there is a race condition issue with the proposed
> > functionality. David's build servers could be quiescent when the
> > check for running processes is perfo
Jason,
On Fri, Jan 17, 2014 at 11:13 AM, Jason Tishler wrote:
> AFAICT, there is a race condition issue with the proposed functionality.
> David's build servers could be quiescent when the check for running
> processes is performed, but they could restart before the rebase is
> finished. I reali
On Thu, Jan 16, 2014 at 09:54:31AM +0100, Corinna Vinschen wrote:
> On Jan 16 01:19, Christopher Faylor wrote:
> > On Wed, Jan 15, 2014 at 11:23:08PM -0500, David Boyce wrote:
> > >Jason et al,
> > >
> > >Here's a suggested new flag (with patch, attached) for
> > >/usr/bin/rebaseall. It adds a -w(a
hi,
i had cron running from a 64bit cygwin install, but i decided to switch
to a 32bit version.
the 32bit cygwin is installed to a differnt directory.
what i did:
running cron-config again from a terminal started as admin.
deinstalling the service via cygrunsrv -R cron and reinstalling via
cr
Hello,
I attach here my tests to clarify:
#Test1 - Only bash
C:\cywin\bin\bash.exe
Result: bash exits. Interactive window not opened.
#Test2 - Two programs
C:\cywin\bin\bash.exe
"%WD%..\BGBINARIES\Window\Window.exe"
Result: Interactive window opened: you can find only Window.exe opened.
#Test
> On 1/16/2014 12:10 PM, BGINFO4X wrote:
>>
>> Hello everybody,
>>
>> I have a "Windows service implementation of cygwin" via NSSM
>> (http://nssm.cc/). I use cygwin 1.7.27 32 bits.
>>
>> If I configure the service as "allow service to interact with
>> desktop", the UIODETEC.exe is not started, so
On Jan 16 23:53, tedno...@bellsouth.net wrote:
> In message <20140116085026.ga26...@calimero.vinschen.de>you write:
> >
> >Can you change your testcase another bit, please? Enable your
> >`ftell' printf, but rather than printing the result of ftell,
> >print the result of lseek:
> >
> > fprintf(s
23 matches
Mail list logo