Mintty is a terminal emulator for Cygwin with a native Windows user
interface and minimalist design. Among its features are Unicode
support and a graphical options dialog. Its terminal emulation is
largely compatible with xterm, but it does not require an X server.
Mintty is based on code from PuTT
Hello all,
I was testing a program written by someone else that calls _stat() (note the
leading underscore). However it was not giving an expected result. Consider
this sample program.
FILE statex.c:
#include
#include
int
main (void)
{
struct stat s;
assert (_stat ("/bin/ls", &s)
Am 27.02.2010, 12:57 Uhr, schrieb Dave Lee :
Is it a problem with _stat(), or did I make a mistake in the 2nd
argument in calling _stat()?
If it (meddling with internal affairs, such as using _stat) hurts too
much, then don't do it (use stat instead, it's standardized).
--
Matthias Andree
> If it (meddling with internal affairs, such as using _stat)
> hurts too much, then don't do it (use stat instead, it's
> standardized).
An off-topic question: on system where both XXX() and _XXX() are available
(where XXX = open, read, write, access, chmod, ... etc), can one assume what
_XXX()
I was running cygwin-1.7 snapshots 20100223. I tried out 20100226 and got the
same issue under cygwin console and mintty. Bash hang under "ESC 24;" sequence.
Some of the cygwin package information is as follows:
Cygwin DLL version info:
DLL version: 1.7.2
Build date: Fri Feb 26 16:41:
Hi,
My application uses the xerces-c-3.0.1 library.
When linking to the library (with libtool), I am getting the following
error message:
/bin/sh ../../libtool --tag=CXX --mode=link g++ -O3 -s -g -O2
-Wl,--enable-auto-import -o libmylib.la mycode.lo -lxerces-c
/usr/bin/grep: /usr/lib/gcc/i686
Johan De Taeye wrote:
> Note the version of libstdc++ the above is trying to find: 4.3.2
> The current version in cywgin is 4.3.4.
>
> It looks to me that the libxerces-c-3.0.1 libraries were created with
> an older version of the compiler and are not up to date any more.
> Is this a bug? Or am I
On 27/02/2010 15:14, Dave Lee wrote:
>> If it (meddling with internal affairs, such as using _stat) hurts too
>> much, then don't do it (use stat instead, it's standardized).
>
> An off-topic question: on system where both XXX() and _XXX() are available
> (where XXX = open, read, write, access, ch
On 27/02/2010 17:03, Charles Wilson wrote:
> Johan De Taeye wrote:
>
>> Note the version of libstdc++ the above is trying to find: 4.3.2
>> The current version in cywgin is 4.3.4.
>>
>> It looks to me that the libxerces-c-3.0.1 libraries were created with
>> an older version of the compiler and ar
On 26/02/2010 22:45, David Rothenberger wrote:
> I know the Cygwin DLL has some "magic" for appending the .exe extension
> and I suspect that's getting in the way here, but I don't know when or
> why it happens.
I believe it happens a lot more if you go using DOS paths(*). Do not do that.
Cyrille Lefevre laposte.net> writes:
... deleted ...
>
> may be you may post your code ?
>
> Regards,
>
> Cyrille Lefevre
Cyrille,
the script is appended in uuencoded form
(due to some lines longer 80 characters).
regards
kf
===
I have a last question that might reminds you something (at least I hope
so)
and unfortunately that is beyond this mailing list but I chance it
I am working on a msys/mingw installer(EasyMingw) where instead of the
default crappy
toolchain(very personal opinion I encourage you to make yours) I am
i
On 27/02/2010 18:19, Vincent Richomme wrote:
> $ gcc test.c
> gcc.exe: CreateProcess: No such file or directory
>
> If instead of putting gcc files inside a usr folder I put it directly the
> archive root it works fine.
Add '-v' to see how gcc is using relative paths to look for cc1.exe (and
p
On 2/27/2010 10:05 AM, Dave Korn wrote:
On 26/02/2010 22:45, David Rothenberger wrote:
I know the Cygwin DLL has some "magic" for appending the .exe extension
and I suspect that's getting in the way here, but I don't know when or
why it happens.
I believe it happens a lot more if you go us
Christopher Faylor a écrit :
On Thu, Feb 25, 2010 at 01:05:06PM +0100, Corinna Vinschen wrote:
On Feb 25 01:30, Paul McFerrin wrote:
A new wrinkle with hard links. If you are testing for them in
pdksh, they will always fail. I.E.:
if test -L links/$filename.$inumb
then :
else
Hi all,
I was testing a program that uses non-canonical mode input via
tcsetattr().
The intent of the program is:
(1) have read() to wait if nothing has been entered;
(2) read() should not return until 1 character is read
and put into the buffer.
The essence is this:
> struct termios
Sorry for forgetting 3 things.
1. I was testing on cygwin 1.7.
2. I was running the latest version of mintty (0.5.8-1).
3. I have included an output from cygcheck here.
Thanks.
--- On Sun, 2/28/10, Dave Lee wrote:
> Hi all,
>
> I was testing a program that uses non-canonical mode input
> via
>
This is a weird problem. Caused by interaction of cygwin 1.7 and
Perfect Disk 7.0 (defragmeter).
A couple of days ago, I was defragmenting my drive C: when I discovered
a copy of every cygwin's file with a naming convention of:
AY63D92E~orig.file.name~. The leading chars were 8 letters/numbe
I discovered a read-only filesystem called /proc/mounts which is
symbolically linked from /etc/mtab.
My question is: who populates this data??
I got a cyclic-loop caused by drive C being mounted twice. as /c and
/cygdrive/c I would like to get rid of the cygdrive one but it is
special trea
Should I always receive the warning dialog about 1.7 even though I
*think* I'm about to download 1.5. That's a scary thought! Well this
dialog is preventing me from continuing. I would feel much better if
either: 1) dialog box suppressed or 2) some other feedback that I'm
downloading a 1.5
--- Dom 28/2/10, Paul McFerrin ha scritto:
> Should I always receive the warning
> dialog about 1.7 even though I *think* I'm about to download
> 1.5. That's a scary thought! Well this dialog is
> preventing me from continuing. I would feel much
> better if either: 1) dialog box suppressed or
21 matches
Mail list logo