Dave Korn wrote:
> Charles Wilson wrote:
>
>> I have a hunch that an STC (okay, less-hellaciously-complicated test
>> case) could be developed, using just GNU pth and avoiding all the
>> libassuan/gnupg gobbledygook.
>
> Oh yuck. So there's this alternative user-land pthreads library that runs
2009/10/17 Eric Backus:
> In passing, I'll note that xterm on my very old and out-of-date SuSE linux
> installation uses DEL, so matches your new version of mintty
Yeah, I think the GNU people managed to browbeat Linux distros into
standardising on ^? some time ago.
>> The workaround is to stick
Charles Wilson wrote:
> I have a hunch that an STC (okay, less-hellaciously-complicated test
> case) could be developed, using just GNU pth and avoiding all the
> libassuan/gnupg gobbledygook.
Oh yuck. So there's this alternative user-land pthreads library that runs a
scheduler within a single
Charles Wilson wrote:
> 1) look at the parent's stack trace when it is inside fork(). Ditto
> its return address.
> 2) after the child longjmp's back into fork() from dll_crt0_1,
> look at its stack trace and return address. (although I can't
> really catch it that early. I can o
Hello,
I've installed all the Cygwin-1.7.0 packages uptodate, on my Windows
XP machine.
I do experience a segmentation fault whenever i launch a program when
the PATH is not set.
When PATH is badly set (but set), nothing happens (and the result is
OK).
See below how to reproduce. When i
Andy Koppe gmail.com> writes:
> 2009/10/16 Eric Backus:
> > Unfortunately, cygwin's terminfo/termcap entries for XTERM say that the
> > backspace key returns ^H. This can be seen by looking in /etc/termcap for
> > xterm, and finding the 'kb' property for that entry, or by running 'infocmp
> > xt
My mistake. I read through the documents - thanks!
So, without any entries in /etc/fstab and with no modifications done via
mount is 'ls' supposed to work on a networked drive? I am finding that it
gives an error. What am I doing wrong? Both B: and N: are networked
drives. I can change direct
On Fri, Oct 16, 2009 at 16:46, James Fuller wrote:
> Just a FWIW post.
> I am a novice at Linux and know very little about cygwin but I did
> have success with BaCon an experimental endeavor located here.
> http://www.basic-converter.org/
>
> Here is the discussion on how I got it working
> http:/
Just a FWIW post.
I am a novice at Linux and know very little about cygwin but I did
have success with BaCon an experimental endeavor located here.
http://www.basic-converter.org/
Here is the discussion on how I got it working
http://www.allbasic.info/forum/index.php?topic=794.0
James
--
Problem
It appears something about the about rsync or the 1.7 version of
cygwin is preventing the --link-destination function of rsync from
working. Files that have not been changed at all should be linked
together. On the hosts still running a cygwin 1.5 version of rsync
the link-destination seems to wo
Dave Korn wrote:
> Charles Wilson wrote:
>
>> ModLoad: 75bd 75c7a000 C:\Windows\system32\msvcrt.dll
>
> Say, what's that doing there? Might like to check who's pulling it in, just
> in case something's gone all win32 on you that shouldn't be.
It appears to be pulled in by winsock2, whic
Charles Wilson wrote:
> ModLoad: 75bd 75c7a000 C:\Windows\system32\msvcrt.dll
Say, what's that doing there? Might like to check who's pulling it in, just
in case something's gone all win32 on you that shouldn't be.
> ModLoad: 6c1b 6c1b5000 C:\Windows\system32\avgrsstx.dll
Let's
Dave Korn wrote:
> Charles Wilson wrote:
>> Help?
>
> Trashed stack?
>
>> I note that procmon indicates that the child process exited with code
>> -1073741783, which in hex is 0xc029. If that's an NTSTATUS value,
>> then it means STATUS_INVALID_UNWIND_TARGET, but that might be a red herrin
2009/10/16 Warren Young:
> Well, on Linux consoles, the term type is "linux". Presumably this is one
> of the reasons they felt they needed a separate term type.
>
> Maybe MinTTY should be emulating something other than xterm, which doesn't
> have this backspace problem? I don't mean something va
Andy Koppe wrote:
2009/10/16 Eric Backus:
Unfortunately, cygwin's terminfo/termcap entries for XTERM say that the
backspace key returns ^H.
xterm does still send ^H, but I agree both xterm and its termcap entry
ought to be changed to match the new Cygwin 1.7 default and the Linux
world. I sh
2009/10/16 Eric Backus:
> Unfortunately, cygwin's terminfo/termcap entries for XTERM say that the
> backspace key returns ^H. This can be seen by looking in /etc/termcap for
> xterm, and finding the 'kb' property for that entry, or by running 'infocmp
> xterm' and looking for the 'kbs' property.
>
Charles Wilson wrote:
> Charles Wilson wrote:
>> Which appears ok, as far as it goes. 'Course, something dies eventually
>> because I never do get to gpg-agent's "exec()" of pinvoke, after that fork.
>
> Well, bad news. In the kernel, the child gets right up to the return
> statement in fork(), re
Andy Koppe gmail.com> writes:
> CHANGES
> ===
>
> Keyboard:
> - The default backspace keycode now is ^? rather than ^H, to make
> Ctrl+H available as a shortcut for other purposes, particularly as the
> help key in emacs. The backspace keycode option is gone. Instead, the
> DECBKM control se
Charles Wilson wrote:
> Which appears ok, as far as it goes. 'Course, something dies eventually
> because I never do get to gpg-agent's "exec()" of pinvoke, after that fork.
Well, bad news. In the kernel, the child gets right up to the return
statement in fork(), returning 0. But it never reaches
On Fri, Oct 16, 2009 at 07:29, Jonathan Grant
wrote:
> Hello
> Anyone else see this output below?
>
> Please include my email address in replies as I am not on this list
> Regards, Jon
>
>
> C:\src>make -j4
>
> ./src/test.c(56) : C0200 (E) No prototype function
> make[1]: *** [obj/test.o] Error 1
Hello
Anyone else see this output below?
Please include my email address in replies as I am not on this list
Regards, Jon
C:\src>make -j4
./src/test.c(56) : C0200 (E) No prototype function
make[1]: *** [obj/test.o] Error 1
make: *** [../../../common/itron/code] Error 2
make: INTERNAL: Exiting w
On Oct 16 10:11, wynfield wrote:
>
>
> The patch would probably solve the same problem for displayging Japanese
> characters.
I hope so. The problem was that the "special folders" like the Windows
system directory were still read using the ANSI version of the Win32
function. This affected all
On Oct 16 00:00, Paul J. Ghosh wrote:
> First off - thanks Corinna - the rxvt/run issue on Windows 7 is
> resolved with 1.7 - thread:
> http://cygwin.com/ml/cygwin/2009-10/msg00372.html
>
> Now onto reporting bugs... I am running cygwin 1.7.0-62 on Windows 7.
>
> 'ls' on network drives is faili
On Oct 15 23:01, Yaakov S wrote:
> It appears that two EXEs can coexist (with the registry setting) but only
> whichever one was so named first will be run:
> [...]
> Bug? Limitation? If it hurts, don't do that?
Limitation. While we can do everything with files using native NT
calls, we can't
On Oct 15 15:20, Charles Wilson wrote:
> Dave Korn wrote:
> > ... who leaves a copy in the -src tarball instead.
> Oh, I didn't know that. Thanks, Dave.
>
> I guess that kinda makes sense; you need the exact source for the .dbg
> to work anyway. I'd been rolling my CVS dir back to the specified
Charles Wilson wrote:
> Dave Korn wrote:
>> Charles Wilson wrote:
>>> I'm not familiar at all with procmon (sysinternals, right?) but I'll
>>> look into it.
>> Yep, it's dead useful for making sure that stuff at least starts up, and
>> you
>> can often get a clue how far the code has got by seei
26 matches
Mail list logo
