Re: Strange behaviour with winsymlinks:native

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

Strange behaviour with winsymlinks:native

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 behaviour (i.e. CYGWIN unset or without a winsymlinks option

Re: strange behaviour of 'ls'

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

Re: strange behaviour of 'ls'

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

Re: strange behaviour of 'ls'

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

Re: strange behaviour of 'ls'

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

Re: strange behaviour of 'ls'

> 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://

Re: strange behaviour of 'ls'

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

strange behaviour of 'ls'

Hello, 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 prefer to have ls perform as expected.

Re: Strange behaviour of mutt.exe

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)

Strange behaviour of mutt.exe

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). Specially, on windows this file has extra B character

strange behaviour of Xfig under cygwin

Dear all, if I try to open a library in 3.2.5b first it takes a long time before the menu open. Than after selecting a Library to load I get a lot of errors File xxx.fig Figure resolution or coordinate specifier missing in line 5 Error reading xxx.fig By the way get this error also if I use

Re: Strange behaviour of CYGWIN in VISTA x64 Ultimate, advice needed

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

Strange behaviour of CYGWIN in VISTA x64 Ultimate, advice needed

Hi all, 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 Ultimate x64 and I have succe

Re: strange behaviour

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

strange behaviour

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. If I start rxvt then '=

Strange behaviour of windres under cygwin....

Hi, I'm banging my head about following problem: ls -l /cygdrive/c/MATLAB~1/extern/include/mexversion.rc gives: -rwxr--r--+ 1 robert None 862 Dec 2 1998 /cygdrive/c/MATLAB~1/extern/include/mexversion.rc and windres -o mexversion.res cygdrive/c/MATLAB~1/extern/include/mexversion.rc -O cof

strange behaviour of xemacs

Hi, I have a Windows XP laptop where I've installed cygwin. I open an xterm using rxvt and log on some linux box: D:\cygwin\bin\rxvt.exe -ls -si -sk -sb -fg black -bg Wheat -fn 7x14 -g 120x24 -T "linappserv2.pp.rhul.ac.uk" -e ssh -X -Y -l linappserv2.pp.rhul.ac.uk I now run xemacs on the

Re: Strange behaviour with g++ 3.4.4-1

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

Re: Strange behaviour with g++ 3.4.4-1

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

Re: Strange behaviour with g++ 3.4.4-1

-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

RE: Strange behaviour with g++ 3.4.4-1

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 +

Re: Strange behaviour with g++ 3.4.4-1

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

RE: Strange behaviour with g++ 3.4.4-1

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 > @@ -

RE: Strange behaviour with g++ 3.4.4-1

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

Strange behaviour with g++ 3.4.4-1

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 reproduces the 'phenomenon' // // test.cpp //

Re: SOLUTION: Strange behaviour with output redirection (MORE information, Bug in awk.exe?)

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Pekka Niiranen on 5/12/2005 9:42 AM: > Commenting out ANY one of those 7 lines fixed the problem. > It seems I was running out of some resources > but cannot explain what is it. > > Is "$(( ))" for arithmetic safer? Anyone? $(( )) is ce

Re: SOLUTION: Strange behaviour with output redirection (MORE information, Bug in awk.exe?)

Pekka Niiranen wrote: Got it! I had 7 following lines ord1=`expr 300` echo "Base ordinal is ${ord1}" ord=`expr ${ord1} + 5`#subsequent module interval counter prev=`expr 0` ctr=`expr 1` count=`expr 0` disp_nb=`expr 264` BEFORE the awk call ${FAWK}/"Number_of_Loops/{print \$3}" subst$1 >${TMPDI

Re: Strange behaviour with output redirection (MORE information, Bug in awk.exe?)

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

Strange behaviour with output redirection

Hi there, I am using the following convention to set variables in Bash: awk -f /"SIMU_included/{print \$3}" subst$1 >${TMPDIR}/$$ [ -s ${TMPDIR}/$$ ] && < ${TMPDIR}/$$ read SIMU For some reason parameter "SIMU" gets set randomly. Could this be due W2K's buffering in creation of temporary file ${TMP

Re: Strange behaviour of Openssh (SOLVED)

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:

Re: Strange behaviour of Openssh

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

Re: Strange behaviour of Openssh

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

Strange behaviour of Openssh

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 (dsa or rsa generated using ssh-keygen )

Re: Strange behaviour in the which command.

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

Strange behaviour in the which command.

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 this a bug? If so how to fix it? Regards, Michel -- Unsubscribe info: http:/

Re: setup "base": strange behaviour of libbz2-1 and libpcre

> In my TODO to review ... Thanks. Everybody is so busy, it's amazing you all do even half of what you actually do do. Fergus -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.ht

Re: setup "base": strange behaviour of libbz2-1 and libpcre

On Wed, 2004-02-18 at 19:11, [EMAIL PROTECTED] wrote: > Sorry, I know this has been asked a while ago but I can't find the Q and I'm > pretty certain there wasn't an A. In my TODO to review. slated for early march (I'm in a huge transition point at the moment). Rob -- GPG key available at:

setup "base": strange behaviour of libbz2-1 and libpcre

Sorry, I know this has been asked a while ago but I can't find the Q and I'm pretty certain there wasn't an A. 1. Choose default "base" setup from internet and run to completion. 2. Immediately choose it again and two new packages are identified for installation: libbz2_1-1.0.2-5 and libpcre0-4.5-1

Strange behaviour w/ read/write

Hi I am using the current cygwin version (dll version 1-5-5-1) and see some strange behaviour while using the read/write system calls. In short: I open a file with mode O_RDWR|O_CREAT, write exactly 1MB into it and then after seeking to position 0 read the Megabyte back. Strange things seem to

Strange behaviour using Cygwin GDB with Linux GDBServer

I am seeing some strange behavior while using Cygwin GDB and connecting to a remote machine via TCP/IP running Linux and GDBServer. The machine running Cygwin is a P4 with Windows 2000, I do have Administer privileges. The version of GDB is 2003-03-03-cvs (cygwin-special), and I have also downloade

Re: strange behaviour in cygwin 1.3.21

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

Re: strange behaviour in cygwin 1.3.21

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

Re: strange behaviour in cygwin 1.3.21

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

strange behaviour in cygwin 1.3.21

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-window. it blocks, and the window

Re: Strange behaviour of gcc

>-- 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: >>

Re: Strange behaviour of gcc

[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

Strange behaviour of gcc

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 b .bss d .data t .text

Re: Strange behaviour of vpath with dos paths

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

Re: Strange behaviour of vpath with dos paths

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

Re: Strange behaviour of vpath with dos paths

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

Re: Strange behaviour of vpath with dos paths

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

Re: Strange behaviour of vpath with dos paths

e AG 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: > > --- >

Re: Strange behaviour of vpath with dos paths

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

Re: Strange behaviour of vpath with dos paths

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

Re: Strange behaviour of vpath with dos paths

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

Re: Strange behaviour of vpath with dos paths

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: > > --- &g

Strange behaviour of vpath with dos paths

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 #vpath %.out /cygdrive/c/make_test/out #VPATH