On Oct 14 15:56, David Allsopp via Cygwin wrote:
> I've been doing some working around the problems with Cygwin 3.1.5+ WSL
> junction points in Docker and found three unexpected pieces of behaviour
> with CYGWIN=winsymlinks:native
>
> In all cases, these work as expected with the default symlink b
Am 08.04.2016 um 20:52 schrieb Achim Gratz:
Thomas Wolff writes:
Like for grep which now barfs out when a character isn’t recognized in
the current encoding (and grep doesn’t even provide an environment
variable to override this mis-feature), these assumedly-modern
upstream changes are a nuisanc
On 04/08/2016 12:52 PM, Achim Gratz wrote:
> Thomas Wolff writes:
>> Like for grep which now barfs out when a character isn’t recognized in
>> the current encoding (and grep doesn’t even provide an environment
>> variable to override this mis-feature), these assumedly-modern
>> upstream changes are
Thomas Wolff writes:
> Like for grep which now barfs out when a character isn’t recognized in
> the current encoding (and grep doesn’t even provide an environment
> variable to override this mis-feature), these assumedly-modern
> upstream changes are a nuisance.
You are barking up the wrng tree, p
On 07.04.2016 13:11, Andrew Schulman wrote:
I have just noticed that the program 'ls' has started to put quotes around some
entries in the listing when I use it
That are not really present around the actual files / directories.
The default quoting style in ls recently changed upstream, and then
> I have just noticed that the program 'ls' has started to put quotes around
> some entries in the listing when I use it
> That are not really present around the actual files / directories.
The default quoting style in ls recently changed upstream, and then made its way
into Cygwin. See https://
Simon Bradley talktalk.net> writes:
> I have just noticed that the program 'ls' has started to put quotes around
> some entries in the listing when I use it
> That are not really present around the actual files / directories.
>
> This is hugely annoying and I do not want this behaviour. I much pr
On 2012-09-07, Stepan Yakovenko wrote:
> HI!
>
> To reproduce the problem, launch mutt from command line:
> mutt -f cygwin.mutt.glitch.eml
>
> open mail and press 'v' to view attachmets. Then press 's' to save
> attachment. Result of saving is different on linux and windows (see
> files attached)
On 07/18/2009, Ulf Lindgren wrote:
before I reinstall my computer, I'd like to get your advice to what may
cause a strange behavior in cygwin bash. I have not found any hints in the
archives so as a last resort perhaps someone reading this knows what is going
on. I run a computer with Vista Ul
Praveen Agrawal wrote:
Hi,
I have got cygwin installed on Vista basic. From today, I am having a
strange problem with xterm. I do startx and then ssh to some machine
for my research work.
Earlier it was working all fine, now '=' keep on echoing on xterm
which makes impossible to type any command
Larry Hall wrote:
At 08:45 AM 9/28/2005, you wrote:
The correct fix, in my opinion, would be to update windef.h to not
define min and max if __cplusplus is defined, since C++ is much less
forgiving of min and max being macros in the first place (in other words,
min and max as macros only works
At 08:45 AM 9/28/2005, you wrote:
>-BEGIN PGP SIGNED MESSAGE-
>Hash: SHA1
>
>According to Andy Moreton on 9/27/2005 7:58 AM:
#include
#include
+#undef max
+#undef min
#include
>>>
>>>
>>
>> The problem is that "windows.h" includes "windef.h" which defines the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Andy Moreton on 9/27/2005 7:58 AM:
>>>
>>> #include
>>> #include
>>>+#undef max
>>>+#undef min
>>> #include
>>
>>
>
> The problem is that "windows.h" includes "windef.h" which defines the
> standard macros min() and max() without chec
On Mon, 26 Sep 2005 21:41:29 GMT, Angelo Graziosi wrote:
>
>
> Dave Korn wrote:
>
>
>> You can fix it like this:
>>
>> [EMAIL PROTECTED] /test/cplus> g++ test.fixed.cpp -o test
>> [EMAIL PROTECTED] /test/cplus> diff -pu test.cpp test.fixed.cpp
>> --- test.cpp2005-09-26 10:52:37.405042000 +
Dave Korn wrote:
You can fix it like this:
#include
#include
+#undef max
+#undef min
#include
or like this:
#include
+#define NOMINMAX
#include
#include
--
Chuck
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/prob
Dave Korn wrote:
> You can fix it like this:
>
> [EMAIL PROTECTED] /test/cplus> g++ test.fixed.cpp -o test
> [EMAIL PROTECTED] /test/cplus> diff -pu test.cpp test.fixed.cpp
> --- test.cpp2005-09-26 10:52:37.405042000 +0100
> +++ test.fixed.cpp 2005-09-26 10:52:26.555119000 +0100
> @@ -
Original Message
>From: Angelo Graziosi
>Sent: 23 September 2005 22:01
> Rebuilding, with GCC 3.4.4-1, a few my Windows applications
> (those that use -mwindows), I have found a compiler error that
> was absent in the build with GCC 3.3.3-3.
>
> I have created the simplest test case that
Hi again,
I managed to isolate the problem to the awk.exe.
Calling like this:
export FAWK; FAWK="awk -F^ --compat --source="
${FAWK}/"SIMU_included/{print \$3}" subst$1 >${TMPDIR}/$$
[ -s ${TMPDIR}/$$ ] && < ${TMPDIR}/$$ read SIMU
works only occassionally. But calling awk without redirection
first
I managed to establish the connection by setting the user that
launches the service in the administrators group. (as explained in
http://www.cygwin.com/ml/cygwin/2003-09/msg00977.html )
Thanks everyone for your precious help.
Chris
On 4/13/05, Christophe Sauthier <[EMAIL PROTECTED]> wrote:
Ok, thanks to that I have a clearer view of the problem : the server
seems to have a setuid problem...
here is the last relevant lines of my log :
debug1: temporarily_use_uid 1003/513 (e=1005/513)
seteuid 1003: Permission denied
Does anybody has got clue how to solve it ?
On 4/12/05, Larry
At 11:55 AM 4/12/2005, you wrote:
>Hi,
>
>I encounter some strange stuff when I try to connect to openssh on my
>server (which is using cygwin) using openssh clients (using cygwin
>too).
>
>The connection is perfect when I have no public keys at all on the
>client side. But as soon as I get any key
On Dec 26 12:26, Michel Van den Bergh wrote:
> Hi,
>
> I am running a recent version of Cygwin.
>
> Problem: the command 'which' seems to return succesfully when it shouldn't.
>
> When I do
>
> which programthatdoesnotexist
> echo $?
>
> I get the value 0.
>
> Can somebody confirm this? Is th
Sven Köhler wrote:
>>> usually, i connect to a host with ssh, and when i'm finished, i just
>>> just hit the close-button of the console-window, which kills bash,
>>> ssh etc.
>>>
>>> now, after upgrading to cygwin 1.3.21, i cannot use the close-button
>>> as usual when i'm using ssh in that consol
usually, i connect to a host with ssh, and when i'm finished, i just
just hit the close-button of the console-window, which kills bash,
ssh etc.
now, after upgrading to cygwin 1.3.21, i cannot use the close-button
as usual when i'm using ssh in that console-window.
it blocks, and the windows-box oc
Sven Köhler wrote:
> hi,
>
> usually, i connect to a host with ssh, and when i'm finished, i just
> just hit the close-button of the console-window, which kills bash,
> ssh etc.
>
> now, after upgrading to cygwin 1.3.21, i cannot use the close-button
> as usual when i'm using ssh in that console-w
>-- Messaggio Originale --
>From: "Max Bowsher" <[EMAIL PROTECTED]>
>To: <[EMAIL PROTECTED]>,
> <[EMAIL PROTECTED]>
>Subject: Re: Strange behaviour of gcc
>Date: Mon, 23 Dec 2002 23:25:00 -
>
>
>[EMAIL PROTECTED] wrote:
>>
[EMAIL PROTECTED] wrote:
> Can somebody explain why gcc (version 3.2 20020927) on Cygwin does
> this? Type this simple C program
>
> void func(void){
> struct {unsigned char data[3985];}var;
> }
>
> and compile with
>
> gcc -c filename.c
>
> Then type
>
> nm filename.o
>
> The output is
>
> 0
Christopher Faylor wrote:
> That means you send the ChangeLog entry (not the diff of a ChangeLog
> entry) and patch in clear text so that the barrier to inspecting your
> work is minimal. This is standard across every project that I am
> aware of.
Sorry for the attachment then. Here it's once a
On Fri, Mar 22, 2002 at 11:23:16AM +0100, Johan Bezem wrote:
>Christopher Faylor wrote:
>
>> >So, my question: Where can I find the repository of the CygWin make
>> >package? Or otherwise, how to proceed from here?
>>
>> You can't. Use the make source tarball and submit ChangeLog + patch
>> here
Christopher Faylor wrote:
> >So, my question: Where can I find the repository of the CygWin make
> >package? Or otherwise, how to proceed from here?
>
> You can't. Use the make source tarball and submit ChangeLog + patch
> here.
OK, here it goes. I'm not aware of standard testing procedures or
On Thu, Mar 21, 2002 at 05:08:45PM +0100, Johan Bezem wrote:
>The GNU make project (http://savannah.gnu.org/projects/make) does not
>contain the CygWin enhancements in its main development tree,
Nope. They were unresponsive in my attempts to get the changes into
the main branch. I sent two requ
Hi,
OK, so I think I fixed the problem with the vpath directive, I fixed
another related problem on the way (the GPATH variable shows the same
symptoms), I tested both fixes on my machine, and wrote a ChangeLog
entry.
Now, I want to contribute these fixes into the development chain for
CygWin mak
Soren Andersen wrote:
>
> On 28 Feb 2002 at 11:24, Colm Aengus Murphy wrote:
>
> > Hi Johan,
> >
> > I took a quick look at source code for make 3.79.1-5.
> >
> > It looks to me like vpath.c (build_vpath_lists) does conversion of Win32
> > paths to posix ones for the VPATH variable but not for v
On 28 Feb 2002 at 11:24, Colm Aengus Murphy wrote:
> Hi Johan,
>
> I took a quick look at source code for make 3.79.1-5.
>
> It looks to me like vpath.c (build_vpath_lists) does conversion of Win32
> paths to posix ones for the VPATH variable but not for vpath. Not being a
> software programmer
Hi Johan,
I took a quick look at source code for make 3.79.1-5.
It looks to me like vpath.c (build_vpath_lists) does conversion of Win32
paths to posix ones for the VPATH variable but not for vpath.
Not being a software programmer I'm not in a position to provide a
patch, but maybe someone els
Hi,
Colm Aengus Murphy wrote:
>
> Hi folks,
>
> I am seeing strange behaviour when using dos paths in a gnu make vpath
> directive.
> The makefile I am using to test this funny is as follows:
>
> ---
> vpath %.out c:/make_test/out
36 matches
Mail list logo
