On Fri, Apr 04, 2014 at 10:51:24PM -0400, Eliot Moss wrote:
> On 4/4/2014 10:29 PM, Duncan Roe wrote:
> >I just found that gdb's "run" command doesn't action redirection (e.g. run
> >/dev/pty2 2>&1, where the shell on /dev/pty2 is doing a long
> >sleep).
> >Instead, the invoked program gets the re
On 4/4/2014 10:29 PM, Duncan Roe wrote:
I just found that gdb's "run" command doesn't action redirection (e.g. run
/dev/pty2 2>&1, where the shell on /dev/pty2 is doing a long sleep).
Instead, the invoked program gets the redirections as command line arguments.
Looking through the archives, I fo
>> I can’t push this through your list spam filter. Another attempt...
I was trying a few times, and finally deleted the strace attachment. Let's see
if this will go through.
Excuse me for being a bit straightforward, but the spam filter this list is
using is *really* stupid!
> Still, you're
I just found that gdb's "run" command doesn't action redirection (e.g. run
/dev/pty2 2>&1, where the shell on /dev/pty2 is doing a long sleep).
Instead, the invoked program gets the redirections as command line arguments.
Looking through the archives, I found
https://sourceware.org/ml/cygwin/1999-
On Fri, Apr 4, 2014 at 10:29 PM, Warren Young wrote:
> Pine is basically dead, partly because of licensing/trademark problems with
> the University of Washington, and partly due to waning interest from that
> same group. (Cite: http://goo.gl/SkfCef)
I guess it's Pine for the fjords.
Csaba
--
G
On 4/4/2014 07:57, J. David Boyd wrote:
I (think I) recall that Pine used to be available in the Cygwin archive.
It no longer is? Any ideas where to get a Cygwin compatible binary?
Pine is basically dead, partly because of licensing/trademark problems
with the University of Washington, and p
Cygwin DLL 1.7.28 32-bit
Windows 8.1 64-bit (build 6.3.9600)
*Steps to reproduce*
1) Open Cygwin bash prompt
2) Type: ssh blargh # or any non-existent host
3) Press Ctrl-C immediately after that
On my machine, the Ctrl-C doesn't stop SSH from trying to look up the
non-existent host, it keeps goi
Christopher Faylor cygwin.com> writes:
> Unless there is an identified regression, the latest snapshot
> is very close to becoming Cygwin version 1.7.29.
The 32bit version (2014-03-29 21:21:42 UTC x86) seems to have at least the
portion of the AD code active that relates to the numerical GID bum
On 4/4/2014 9:54 AM, Václav Zeman wrote:
Hi.
TeXLive post install script exits with error for me. I am attaching
cygcheck output and mllatex.log with the errors.
Thanks for the report. The error is actually harmless (unless you want
to use mllatex), but it should go away if you issue the fol
I (think I) recall that Pine used to be available in the Cygwin archive.
It no longer is? Any ideas where to get a Cygwin compatible binary?
Dave
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/doc
On 4/4/2014 6:59 AM, Václav Zeman wrote:
On 30 June 2013 18:32, Ken Brown wrote:
On 6/30/2013 12:04 PM, Helmut Karlowski wrote:
Ken Brown, 30.06.2013 16:36:40:
I'm glad you found it. Does the malformed environment string also
explain the other strange errors you were seeing?
During texl
On Apr 4 09:44, Colin wrote:
> Corinna Vinschen cygwin.com> writes:
>
> > > In discussing this with the embedded PC supplier, he suggests that the
> > > cygwin1.dll is exiting because it doesn't recognise the CPU. Is this
> > > explanation plausible? And if it is, is there a solution available
Yaakov (Cygwin/X users.sourceforge.net> writes:
>
> Therefore, in order to even attempt to make this work, you would have to
> recompile gcc for -march=i586 default, then rebuild *everything* with
> that gcc; but I can't guarantee that there won't be other issues as well.
>
> Yaakov
>
> [1]
Corinna Vinschen cygwin.com> writes:
> > In discussing this with the embedded PC supplier, he suggests that the
> > cygwin1.dll is exiting because it doesn't recognise the CPU. Is this
> > explanation plausible? And if it is, is there a solution available, or
> > must I give up on using cygwin
On 2014-04-02 18:03, Colin wrote:
The problem I have can be reduced to this: I compile a simple "Hello
World" console mode c program. I copy the .exe file and cygwin1.dll onto
an embedded PC, open a console window, and run the program. The program
runs, and returns immediately to the command prom
On Apr 2 23:03, Colin wrote:
> Hi Team,
>
> I'm new here, but have dabbled in Cygwin for a few years. I hope someone
> more knowledgeable than myself can help with with this issue which is
> quite frankly baffling me for the past few weeks.
>
> The problem I have can be reduced to this: I comp
On Apr 3 22:41, Angelo Graziosi wrote:
> Corinna Vinschen wrote:
> >Could you please send the link to the PR to this thread?
>
> Obviosly... I just hope I did everything right.
>
> This should be PR binutils/16807, i.e.
>
> https://sourceware.org/bugzilla/show_bug.cgi?id=16807
Perfect!
Thank
René Berber computer.org> writes:
>
> What you usually do on those cases:
>
> 1. On the build host, run ldd (or cygcheck) on the program, see the full
> list of dynamic libraries used.
>
> 2. Try to do the same on the target host. Yes, ldd does depend on
> cygwin1.dll, so it may not run.
18 matches
Mail list logo
