Re: How to close a SSH connection from a BAT file

[Sylvain Richard]

Anthony de Sousa wrote:
the next time that net start ssh is issued the following 
errors are in the log

bind: Address already in use
channel_setup_fwd_listener: cannot listen to port: 139
Could not request local forwarding

Re your port 139 problem, see:

http://www.blisstonia.com/eolson/notes/smboverssh.php


You can check that port 139 is owned by your ssh client by using:
netstat -ano
tasklist /svc
or (more easily):
netstat -abn

Some webpages suggest stopping the "server" process but then you'd lose 
the shares hosted by your client machines.


Best of luck

Sylvain

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: How to close a SSH connection from a BAT file

[Anthony de Sousa]

Anthony de Sousa  csc.com> writes:

> 

> 
> I would like to conclude that we have decided to use AUTOSSH to control ssh. 
With autossh the processes are stoped automatically whenever autossh is 
stoped. As Brian originally suggested all that is then required on either side 
of the bat file is a Net Start Autossh and a Net Stop Autossh. Many Thanks




--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: cygwin compliation crash when uninstalling the old version of bash

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Please keep replies on the list - http://cygwin.com/acronyms/#PPIOSPE

According to wei on 8/20/2007 12:16 PM:
> Hi Eric
> 
>> And what did the popup say?  Nothing in your cygcheck output is jumping
>> out at me as unusual, but without knowing what the crash said, I don't
>> know the full picture.

> I just recompiled the cygwin from scratch after delete the previous
> directory to bypass the problem.

You still didn't describe the problem, but I'm glad you seem to have
resolved this.


- --
Don't work too hard, make some time for fun as well!

Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGyjyf84KuGfSFAYARAi/ZAKClqI+VWH1/kII92ZaUe00rBRHBEQCg0vbV
NxypnUpNPYxmj8HUoGrg3W4=
=p1+h
-END PGP SIGNATURE-

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Line info causes GCC to bomb?

[g6522c]

-Original Message-
>From: Brian Dessent <[EMAIL PROTECTED]>
>Sent: Aug 20, 2007 7:40 AM
>To: cygwin@cygwin.com

>I wouldn't spend too much effort on that.  It's fixed in 4.x, and the
>3.x branches were closed a long time ago.  OTOH, it might be nice to
>have this fixed in the Cygwin-distributed gcc; however since it seems to
>be a rather esoteric corner case it's not a huge priority.

I mostly wanted to dutifully note the issue.  As I indicated, it's easy to work 
around for me, and if someone decides to upgrade the Cygwin package they might 
need to be aware of it.

Thanks again,

Robert



Ctalk Project Home Page: http://ctalk-lang.sourceforge.net
Mailing List:  [EMAIL PROTECTED]


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: rsync problems from Vista installed cygwin, ok on XP

[DaveB]

Igor Peshansky wrote:
> 
> On Mon, 20 Aug 2007, DaveB wrote:
> 
>> Corinna Vinschen-2 wrote:
>> >
>> > On Aug 18 21:06, DaveB wrote:
>> >> So... two interesting followon points...
>> >>
>> >> 1. Why didn't the ACLs get set to something reasonable as opposed to
>> >> 000 in the first place when I created this little test area in Vista?
>> >> After all, I
>> >
>> > The directory has been created using native Windows tools.  The
>> > permissions given using native Windows tools *are* strange and don't
>> > follow POSIX rules. It's perfectly valid that you can access a
>> > directory under Windows but get 000 POSIX permissions.  You did see
>> > the '+' at the end of the permission in ls -l?
>>
>> OK, I now see this + and had no idea what it meant... but have now found
>> the doc in cygwin by typing "info ls", where it says...
>>
>>  Following the file mode bits is a single character that specifies
>>  whether an alternate access method such as an access control list
>>  applies to the file.  When the character following the file mode
>>  bits is a space, there is no alternate access method.  When it is
>>  a printing character, then there is such a method.
>>
>>  For a file with an extended access control list, a `+' character is
>>  listed.  Basic access control lists are equivalent to the
>>  permissions listed, and are not considered an alternate access
>>  method.
>>
>> Interesting.  So if it knows there is an ACL which overrides the --
>> permissions that were inherited from C:\ then why can't the cygwin port
>> of rsync allow a Windows-friendly option for rsync'ing these files...
>> even if it cannot directly read the ACL maybe it could allow you to
>> invoke some special rsync permissions sync'ing flag?
>>
>> I looked in the man rsync doc, and found some flags that might be
>> helpful ... namely -p -E and --chmod.  But even chmod=XXX doesn't quite
>> let you do automatically what would make sense, which is to create
>> rsync'd files with rwx for the exe's and rw for the others.
>>
>> Not sure what the best way out of here is...??? I'm beginning to
>> understand this a bit better, but it sure is a minefield... will
>> generate ongoing problems for innocent future users.
> 
> You misunderstand your problem.  The problem is not that rsync on the
> source side cannot read the files (it can, since the ACLs allow it to).
> The problem is that the rsync on the destination side copies only the Unix
> permission bits from the source side (which are 000), and then it is
> unable to write to that directory (because the permissions are 000).
> 
> What you want is some way of getting rsync to not copy permissions, or
> making rsync ACL-aware.  I don't know of any way to do either, but then, I
> haven't used rsync extensively.  Perhaps the documentation holds the
> answer.
> 
>> PS Can anyone point to a good article on ACL that explains the
>> relationship to these ls -l permissions also?
> 
> I'm sure MSDN has a lot of info on ACLs in general and on their use in
> Windows.  If you want to know specifically how Cygwin maps ACLs to Unix
> permission bits, see .
>   Igor
> 

Don't think I misunderstood... what I was saying above agrees with you - the
ACLs allow cygwin/rsync to read the files, but it then proceeds to transfer
the posix permissions, which are 000.
The ntsec article above is very helpful actually, explaining the problem
more clearly - there is a mismatch between posix and NT security. cygwin is
an environment trying to bridge the gap.

It seems that a good solution might be to provide a cygwin environment
variable which "OR"s the read/write access of the current user with the
posix flags right from the start... Then even an ls -l would come up with
rwx where applicable (instead of --- at the moment), and programs like
cygwin/rsync would then behave themselves and cause less of a surprise to
the end user.

My earlier comment said
>why can't the cygwin port of rsync allow a Windows-friendly option for
rsync'ing these files
If there was a Windows friendly env variable that made current ACL the
default reported security setting for the rwx flag (at least for the owner)
then there would be no need to fiddle with anything in rsync, fix the
problem upstream.  Cygwin does things like this in other areas - eg it
provides env variables for dealing better with the case dependence in
filenames which is fundamentally different between unix and Windows.  So why
not make it behave more like Windows in the security area?  Until it was
pointed out to me what was going on here, I was oblivious to the --- posix
setting and happily reading and writing files in this directory in Windows,
so of course it was a surprise when rsync's copy of the directory to a unix
system zapped the rwx setting of the directory copy up there.  As Igor is
saying, this is the underlying problem...

>The problem is not that rsync on the
>source side cannot re

Re: Cygwin: Problem detecting subprocess termination after _spawn_posix in distutils?

[Steve Holden]

Steve Holden wrote:

Martin v. Löwis wrote:
The only environment variables that don't appear in the shell output 
from the env command are INFOPATH, MAKE_MODE and PLAT. I am still flummoxed.

At this point, I'd recommend to perform a cygwin update; with Cygwin,
these problems often go away with an update.


I updated Cygwin and did a rebaseall before posting.


If that doesn't help, you can ask on the Cygwin list also; to analyse
this further, ISTM one will need to debug the internals of cygwin.


I posted on Cygwin before asking here.


One thing you could try is to add -v to the list of gcc options;
you can then see whether gcc is progressing correctly.

I'll do that, though I have reason to believe the gcc *is* terminating 
and _spawn_posix isn't detecting the end of the process. At the very 
least we should get another test out of this dreadfully irritating bug.


Thanks again for looking at this.

A further data point (sorry, I've not had a lot of time to look at 
this). Building Python from the trunk at rev 57076 yielded a system that 
*would* cleanly build the same release of PIL. This is somewhat annoying 
because it appears to put the bug in the past where there's less 
incentive to investigate it. But I may find time to take a look.


Hardly worth it if I'm the only one noticing the issue, though.

regards
 Steve
--
Steve Holden+1 571 484 6266   +1 800 494 3119
Holden Web LLC/Ltd   http://www.holdenweb.com
Skype: holdenweb  http://del.icio.us/steve.holden
--- Asciimercial --
Get on the web: Blog, lens and tag the Internet
Many services currently offer free registration
--- Thank You for Reading -

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

symbolic link untar issue

[Tom Rodman]

These steps 'hide bash', so invoking bash again fails:

  /tmp $ uname -a
  CYGWIN_NT-5.0 argon 1.5.24(0.156/4/2) 2007-01-31 10:57 i686 Cygwin
  /tmp $ tar tvf bar.tar
  drwxrwxr-x staffuser1/XYZ_ES_STAFF 0 2007-08-20 17:29 ZZ/
  lrwxrwxrwx staffuser1/XYZ_ES_STAFF 0 2007-08-20 17:29 ZZ/bash2 -> /bin/bash
  /tmp $ tar xpf bar.tar; tar xpf bar.tar #2nd untar does the damage
  /tmp $ ls -l /bin/bash
  -- 1 adm_usr1 None 0 Aug 20 18:03 /bin/bash
  /tmp $ ls -l /bin/bash.exe
  -rwxrwxrwx 1 Administrator Users 470528 May  1 21:22 /bin/bash.exe*
  /tmp $ bash
  -bash: /usr/bin/bash: Permission denied

Notice the zero byte file '/bin/bash' w/o any perms; it causes subsequent
invocations of bash to fail.  It is the 2nd untar that does it.

Here's what is in 'bar.tar' ( which is also attached ):

  /tmp/ZZ $ md5sum /tmp/bar.tar
  0a3b22f3e6d00c68f7000b4fc1b80993 */tmp/bar.tar
  /tmp $ cd ZZ
  /tmp/ZZ $ cmd /c dir
   Volume in drive D has no label.
   Volume Serial Number is BC28-E542

   Directory of d:\aut\cyg\tmp\ZZ

  08/20/2007  05:29p.
  08/20/2007  05:29p..
  08/20/2007  06:03p 108 bash2.lnk
 1 File(s)108 bytes
 2 Dir(s) 544,944,128 bytes free
  /tmp/ZZ $ cmd /c type bash2.lnk|command od -Ad -c
  000   L  \0  \0  \0 001 024 002  \0  \0  \0  \0  \0 300  \0  \0  \0
  016  \0  \0  \0   F  \f  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0
  032  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0
  048  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0 001  \0  \0  \0
  064  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \t  \0   /   b
  080   i   n   /   b   a   s   h 023  \0   d   :   \   a   u   t   \
  096   c   y   g   \   b   i   n   \   b   a   s   h
  108

Is that an old style cygwin snybolic link?  If so how do I identify all of them,
so I might update them on my system?

--
thanks,
Tom Rodman

--
Cleanup.., how to delete the zero byte '/bin/bash':

  /tmp/ZZ $ (cd /bin ; chmod 777 bash;cmd /c del bash; ls -l bash)
  -rwxrwxrwx 1 Administrator Users 470528 May  1 21:22 bash*

--


bar.tar.gz
Description: Binary data
--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Latest mutt (1.4.2.2-1) does not work on (my) XP

[Christopher Faylor]

On Mon, Aug 20, 2007 at 11:35:37PM +0100, Pedro Alves wrote:
>On Mon, Aug 20, 2007 at 06:21:38PM -0400, Christopher Faylor wrote:
>> 
>> What does "tried different temp dirs" mean?  How did you try them?  By
>> setting an environment variable.
>
>editing ~/.muttrc's tmpdir property
>
>> Please provide a *specific* operation that does not work.
>
>The simplest one, pressing '?' for help. Also, pressing enter to see a
>message does not work, always returns the same error and a file with size 0
>is created in the temp dir

Sorry but WJFFM.

 vv
>Problem reports:   http://cygwin.com/problems.html
 ^^

cgf

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Latest mutt (1.4.2.2-1) does not work on (my) XP

[Pedro Alves]

On Mon, Aug 20, 2007 at 06:21:38PM -0400, Christopher Faylor wrote:
> 
> What does "tried different temp dirs" mean?  How did you try them?  By
> setting an environment variable.

editing ~/.muttrc's tmpdir property


> 
> Please provide a *specific* operation that does not work.

The simplest one, pressing '?' for help. Also, pressing enter to see a
message does not work, always returns the same error and a file with size 0
is created in the temp dir

>gwin.com/faq/

-- 
Pedro Alves

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Latest mutt (1.4.2.2-1) does not work on (my) XP

[Christopher Faylor]

On Mon, Aug 20, 2007 at 10:57:52PM +0100, Pedro Alves wrote:
>I can't run latest mutt, version mutt-1.4.2.2-1 on my XP. For every
>operation I try to do I get an error like 'cannot create temporary file'.
>It's not a permission problem... files are created (even tried different
>temp dirs) with 0 size.

What does "tried different temp dirs" mean?  How did you try them?  By
setting an environment variable.

Please provide a *specific* operation that does not work.

>Tips appreciated.

Ditto.

 vv
>Problem reports:   http://cygwin.com/problems.html
 ^^

cgf

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Latest mutt (1.4.2.2-1) does not work on (my) XP

[Pedro Alves]

Hello.


I can't run latest mutt, version mutt-1.4.2.2-1 on my XP. For every
operation I try to do I get an error like 'cannot create temporary file'.
It's not a permission problem... files are created (even tried different
temp dirs) with 0 size.


Reverting to version 1.4.2.1i-1 everything works.


I don't know what changed, but the main binary of 1.4.2.1i-1 has 539136
bytes and 1.4.2.2-1 has 1554944 bytes (3 times more).


Tips appreciated.


Thanks

-- 
Pedro Alves

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Problem building GCC on Cygwin on Vista

[Aaron Gray]

Why is it different from gcc-4.2.0's ?


Okay I am kicking myself now many hours wasted it was because I used a 
Windows program WinRAR to unpack my work rather than using tar !!!


It was a permissions problem afterall.

Very sorry for poluting your mailing list.

Regards,

Aaron


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Problem building GCC on Cygwin on Vista

[Aaron Gray]

Okay getfacl is reporting 'user::---' rather than 'user::rwx' for depcomp on 
my patched version of GCC.


This leads to two questions ...

How do I modify this to be correct ?

Why is it different from gcc-4.2.0's ?

Thanks for bearing with me.

Aaron


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Problem building GCC on Cygwin on Vista

[Aaron Gray]

Ignore the previous post depcomp is under src/gcc-4.2.0 not build/gcc-4.2.0 
!


Sorry to mess you about. I'll get some ACL results now ...

Aaron


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Problem building GCC on Cygwin on Vista

[Aaron Gray]

Okay I printed out '$am_depcomp' which was effectivly 
'gcc4.2.0/libcpp/../depcomp' and put an 'exit' at (effective) line 2888 and 
the file gcc4.2.0/depcomp does not seem to exist.


Very strange as I found 'depcomp' before previously and its printing 'line: 
2888: ./depcomp: permisssion denied' rather than 'file not found' still.


Is this just another missing Cygin package again ?

Aaron


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Problem building GCC on Cygwin on Vista

[Aaron Gray]

Aaron Gray wrote:


A Windows text editor called Zeus.


That's it.  I bet the problem disappears if you use a Cygwin text editor
such as vim.

When a native Windows app creates a file, it usually does not do
anything special with the ACL, so it gets whatever the default
inheritable permissions of the directory happen to be, which it looks
like are not correct.

You could also try a native editor that edits in-place instead of the
usual "create new file with temporary name then rename".


Except its not a file I have editted that is causing the problem, they are 
all behaving fine.


Things are a bit slow at this end due to other tasks and I am running out of 
time before I am back home away from my Vista machine at my parents so this 
may have to be put on hold as getting back to the original problem place is 
taking longer than I though and producing meaning full results from 
examining source will take a while.


Hopefully I will have some results soon...

Aaron


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Problem building GCC on Cygwin on Vista

[Brian Dessent]

Aaron Gray wrote:

> A Windows text editor called Zeus.

That's it.  I bet the problem disappears if you use a Cygwin text editor
such as vim.

When a native Windows app creates a file, it usually does not do
anything special with the ACL, so it gets whatever the default
inheritable permissions of the directory happen to be, which it looks
like are not correct.

You could also try a native editor that edits in-place instead of the
usual "create new file with temporary name then rename".

Brian

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

RE: Problem building GCC on Cygwin on Vista

[Dave Korn]

On 20 August 2007 19:13, Aaron Gray wrote:

>> On 20 August 2007 18:16, Aaron Gray wrote:

>>> Hopefully I shall get to the bottom of it if I perservere, but any help or
>>> suggestions are welcome.
>> 
>>  Well, why don't you actually *look* at those perms, instead of asking people
>> who have no access to your computer and no idea what you've been doing to 
>> make
>> random guesses?  All your descriptions are way too vague for any attempt at
>> remote diagnosis.
> 
> Sorry I will have a look but I am not very strong in this area.


  Feel free to post the results of cacls and getfacl back here when you've got
them, but until then, we're basically toiletless[*] in this matter.


cheers,
  DaveK

[*] -  Y'know.  Nothing to go on.
-- 
Can't think of a witty .sigline today


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Problem building GCC on Cygwin on Vista

[Aaron Gray]

On 20 August 2007 18:16, Aaron Gray wrote:

Unmodified GCC 4.2.0 compiles okay, but when modified cracks appear, 
only
on Vista though, XP is okay. So must be something to do with 
permissions.


 So, what tool did you use to 'modify' it?


A Windows text editor called Zeus.

I have been altering the C source code and some configureation and
gcc/makefile but AFAICT nothing that should effect gcc/configure though.

Its all very odd.

Hopefully I shall get to the bottom of it if I perservere, but any help 
or

suggestions are welcome.


 Well, why don't you actually *look* at those perms, instead of asking 
people
who have no access to your computer and no idea what you've been doing to 
make
random guesses?  All your descriptions are way too vague for any attempt 
at

remote diagnosis.


Sorry I will have a look but I am not very strong in this area.

Aaron


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

RE: Problem building GCC on Cygwin on Vista

[Dave Korn]

On 20 August 2007 18:16, Aaron Gray wrote:

>>> Unmodified GCC 4.2.0 compiles okay, but when modified cracks appear, only
>>> on Vista though, XP is okay. So must be something to do with permissions.
>> 
>>  So, what tool did you use to 'modify' it?
> 
> A Windows text editor called Zeus.
> 
> I have been altering the C source code and some configureation and
> gcc/makefile but AFAICT nothing that should effect gcc/configure though.
> 
> Its all very odd.
> 
> Hopefully I shall get to the bottom of it if I perservere, but any help or
> suggestions are welcome.

  Well, why don't you actually *look* at those perms, instead of asking people
who have no access to your computer and no idea what you've been doing to make
random guesses?  All your descriptions are way too vague for any attempt at
remote diagnosis.

cheers,
  DaveK
-- 
Can't think of a witty .sigline today


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Problem building GCC on Cygwin on Vista

[Aaron Gray]

On 20 August 2007 17:42, Aaron Gray wrote:


On Aug 20 16:20, Dave Korn wrote:


  BTW, you didn't by any chance use winzip to unpack the tarball did 
you?


No.


 Just checking.  Windoze tools don't generally do the right thing for
cygwin's emulation of posix perms.


Apart from that, the file permission settings are the same in Vista
compared to older OSes.  The exception is the UAC stuff which could
result in some executables having less permissions than usual, if, for
instance, Internet Explorer has been used to download the executable.
We can hopefully rule this out here, so it's just some permission
problem which has nothing to do with the base OS.


 I want to throw an AYS in Corinna's general direction here... one of the
ongoing problems in 'doze security since wy back when is that the 
default
perms for user-created files, the equivalent of the default umask under 
posix,

have always been pretty wide open: AYS they haven't been tightened up for
Vista?


Works fine on XP. The only things that are diferent are the Cygwin
instillation and Vista.


 Heh, so that's a bit like saying "The only things that are different are
everything, apart from the gcc source code".

Unmodified GCC 4.2.0 compiles okay, but when modified cracks appear, only 
on

Vista though, XP is okay. So must be something to do with permissions.


 So, what tool did you use to 'modify' it?


A Windows text editor called Zeus.

I have been altering the C source code and some configureation and 
gcc/makefile but AFAICT nothing that should effect gcc/configure though.


Its all very odd.

Hopefully I shall get to the bottom of it if I perservere, but any help or 
suggestions are welcome.


Aaron


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

RE: REAL Problem building GCC on Cygwin on Vista

[Dave Korn]

On 20 August 2007 17:42, Aaron Gray wrote:

>> On Aug 20 16:20, Dave Korn wrote:

>>>   BTW, you didn't by any chance use winzip to unpack the tarball did you?
> 
> No.

  Just checking.  Windoze tools don't generally do the right thing for
cygwin's emulation of posix perms.

>> Apart from that, the file permission settings are the same in Vista
>> compared to older OSes.  The exception is the UAC stuff which could
>> result in some executables having less permissions than usual, if, for
>> instance, Internet Explorer has been used to download the executable.
>> We can hopefully rule this out here, so it's just some permission
>> problem which has nothing to do with the base OS.

  I want to throw an AYS in Corinna's general direction here... one of the
ongoing problems in 'doze security since wy back when is that the default
perms for user-created files, the equivalent of the default umask under posix,
have always been pretty wide open: AYS they haven't been tightened up for
Vista?

> Works fine on XP. The only things that are diferent are the Cygwin
> instillation and Vista.

  Heh, so that's a bit like saying "The only things that are different are
everything, apart from the gcc source code".

> Unmodified GCC 4.2.0 compiles okay, but when modified cracks appear, only on
> Vista though, XP is okay. So must be something to do with permissions.

  So, what tool did you use to 'modify' it?


cheers,
  DaveK
-- 
Can't think of a witty .sigline today


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: REAL Problem building GCC on Cygwin on Vista

[Aaron Gray]

On Aug 20 16:20, Dave Korn wrote:

On 20 August 2007 15:49, Aaron Gray wrote:
>>> On 19 August 2007 20:22, Aaron Gray wrote:
> AFACT this actually looks like a Vista problem.
> [...]
  Hm, that sounds like a file that you have write but not delete
permissions
to.

> Can someone look into this please,

  Well, just to state the obvious, /you/ would be the most ideally-placed
person to do so.

  I don't even have Vista, so I'm kinda ruled out there, but I'd take a
look
at the perms and ACLs of conftest.dir and the existing depcomp file in
there,
using both 'getfacl' to show cygwin's view of the posix-style perms, and
'cacls' to compare with windoze's opinion.

  BTW, you didn't by any chance use winzip to unpack the tarball did you?


No.


Apart from that, the file permission settings are the same in Vista
compared to older OSes.  The exception is the UAC stuff which could
result in some executables having less permissions than usual, if, for
instance, Internet Explorer has been used to download the executable.
We can hopefully rule this out here, so it's just some permission
problem which has nothing to do with the base OS.


Works fine on XP. The only things that are diferent are the Cygwin
instillation and Vista.


 Note: Not all
problems on Vista are Vista's (or, FWIW, Cygwin's) fault.  See, for
example http://cygwin.com/acronyms/#PEBCAK for one possible explanation
of the problem.


Nice reply :)

Does look like a case of PEBCAK.

Unmodified GCC 4.2.0 compiles okay, but when modified cracks appear, only on 
Vista though, XP is okay. So must be something to do with permissions.


Aaron


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: permissions/owners seen on cygwin-client vs. server

[Christopher Faylor]

On Mon, Aug 20, 2007 at 12:11:56PM -0400, Igor Peshansky wrote:
>On Fri, 17 Aug 2007, Linda Walsh wrote:
>>As for including cygcheck, I don't have a problem doing that when
>>necessary, but I prefer to check that it's not some "braino", or that
>>it is a "real" problem before attaching a full cygdump.
>
>How will we know if it's a real problem unless you include the cygcheck
>output?

Right.  There is no harm in including it and, since it is more than
likely that we'd need it, including it eliminates one information-free
cycle of email.

cgf

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: rsync problems from Vista installed cygwin, ok on XP

[Igor Peshansky]

On Mon, 20 Aug 2007, DaveB wrote:

> Corinna Vinschen-2 wrote:
> >
> > On Aug 18 21:06, DaveB wrote:
> >> So... two interesting followon points...
> >>
> >> 1. Why didn't the ACLs get set to something reasonable as opposed to
> >> 000 in the first place when I created this little test area in Vista?
> >> After all, I
> >
> > The directory has been created using native Windows tools.  The
> > permissions given using native Windows tools *are* strange and don't
> > follow POSIX rules. It's perfectly valid that you can access a
> > directory under Windows but get 000 POSIX permissions.  You did see
> > the '+' at the end of the permission in ls -l?
>
> OK, I now see this + and had no idea what it meant... but have now found
> the doc in cygwin by typing "info ls", where it says...
>
>  Following the file mode bits is a single character that specifies
>  whether an alternate access method such as an access control list
>  applies to the file.  When the character following the file mode
>  bits is a space, there is no alternate access method.  When it is
>  a printing character, then there is such a method.
>
>  For a file with an extended access control list, a `+' character is
>  listed.  Basic access control lists are equivalent to the
>  permissions listed, and are not considered an alternate access
>  method.
>
> Interesting.  So if it knows there is an ACL which overrides the --
> permissions that were inherited from C:\ then why can't the cygwin port
> of rsync allow a Windows-friendly option for rsync'ing these files...
> even if it cannot directly read the ACL maybe it could allow you to
> invoke some special rsync permissions sync'ing flag?
>
> I looked in the man rsync doc, and found some flags that might be
> helpful ... namely -p -E and --chmod.  But even chmod=XXX doesn't quite
> let you do automatically what would make sense, which is to create
> rsync'd files with rwx for the exe's and rw for the others.
>
> Not sure what the best way out of here is...??? I'm beginning to
> understand this a bit better, but it sure is a minefield... will
> generate ongoing problems for innocent future users.

You misunderstand your problem.  The problem is not that rsync on the
source side cannot read the files (it can, since the ACLs allow it to).
The problem is that the rsync on the destination side copies only the Unix
permission bits from the source side (which are 000), and then it is
unable to write to that directory (because the permissions are 000).

What you want is some way of getting rsync to not copy permissions, or
making rsync ACL-aware.  I don't know of any way to do either, but then, I
haven't used rsync extensively.  Perhaps the documentation holds the
answer.

> PS Can anyone point to a good article on ACL that explains the
> relationship to these ls -l permissions also?

I'm sure MSDN has a lot of info on ACLs in general and on their use in
Windows.  If you want to know specifically how Cygwin maps ACLs to Unix
permission bits, see .
Igor
-- 
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED] | [EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_Igor Peshansky, Ph.D. (name changed!)
 |,4-  ) )-,_. ,\ (  `'-'   old name: Igor Pechtchanski
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

Belief can be manipulated.  Only knowledge is dangerous.  -- Frank Herbert

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: permissions/owners seen on cygwin-client vs. server

[Igor Peshansky]

On Fri, 17 Aug 2007, Linda Walsh wrote:


Corinna Vinschen wrote:
> Larry is right, of course, but I make a wild guess, nevertheless:
>
>   CYGWIN=nosmbntsec
---
Assuming you mean having that string in the CYGWIN env var,
unfortunately, this is not the case.


See  -- nosmbntsec
is the default.  You need to turn it on to get ntsec functionality on
remote drives.


As for including cygcheck, I don't have a problem doing that
when necessary, but I prefer to check that it's not some "braino", or
that it is a "real" problem before attaching a full cygdump.


How will we know if it's a real problem unless you include the cygcheck
output?
Igor
--
http://cs.nyu.edu/~pechtcha/
 |\  _,,,---,,_ [EMAIL PROTECTED] | [EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_Igor Peshansky, Ph.D. (name changed!)
|,4-  ) )-,_. ,\ (  `'-'old name: Igor Pechtchanski
   '---''(_/--'  `-'\_) fL  a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

Belief can be manipulated.  Only knowledge is dangerous.  -- Frank Herbert

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: REAL Problem building GCC on Cygwin on Vista

[Corinna Vinschen]

On Aug 20 16:20, Dave Korn wrote:
> On 20 August 2007 15:49, Aaron Gray wrote:
> >>> On 19 August 2007 20:22, Aaron Gray wrote:
> > AFACT this actually looks like a Vista problem.
> > [...]
>   Hm, that sounds like a file that you have write but not delete permissions
> to.
>  
> > Can someone look into this please,
> 
>   Well, just to state the obvious, /you/ would be the most ideally-placed
> person to do so.
> 
>   I don't even have Vista, so I'm kinda ruled out there, but I'd take a look
> at the perms and ACLs of conftest.dir and the existing depcomp file in there,
> using both 'getfacl' to show cygwin's view of the posix-style perms, and
> 'cacls' to compare with windoze's opinion.
> 
>   BTW, you didn't by any chance use winzip to unpack the tarball did you?

Apart from that, the file permission settings are the same in Vista
compared to older OSes.  The exception is the UAC stuff which could
result in some executables having less permissions than usual, if, for
instance, Internet Explorer has been used to download the executable.
We can hopefully rule this out here, so it's just some permission
problem which has nothing to do with the base OS.  Note: Not all
problems on Vista are Vista's (or, FWIW, Cygwin's) fault.  See, for
example http://cygwin.com/acronyms/#PEBCAK for one possible explanation
of the problem.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  cygwin AT cygwin DOT com
Red Hat

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

RE: Line info causes GCC to bomb?

[Dave Korn]

On 20 August 2007 12:40, Brian Dessent wrote:

> g6522c wrote:
> 
>> If I can locate the relevant routines in gcc I might be able to provide a
>> patch.  My 
> 
> I wouldn't spend too much effort on that.  It's fixed in 4.x, and the
> 3.x branches were closed a long time ago.  OTOH, it might be nice to
> have this fixed in the Cygwin-distributed gcc; however since it seems to
> be a rather esoteric corner case it's not a huge priority.

  It's not that likely that I'll spin any more cygwin 3.x releases, unless
there's huge demand for it or some bug crops up that impacts a lot of people
in everyday use, but please do Cc me if you generate any patch, because it
might just happen.


cheers,
  DaveK
-- 
Can't think of a witty .sigline today


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

RE: REAL Problem building GCC on Cygwin on Vista

[Dave Korn]

On 20 August 2007 15:49, Aaron Gray wrote:

>>> On 19 August 2007 20:22, Aaron Gray wrote:
>> Now I having a problem with libcpp getting the error :-
>> 
>>checking dependancy style of gcc...
>> /usr/src/gcc-4.2.0/libcpp/configure: line 2887: ./depcomp: premission
>> denied.
> 
> AFACT this actually looks like a Vista problem.
> 
> I replaced line 2875 with :-
> 
> cat "$am_depcomp" > conftest.dir/depcomp
> 
> from
> 
> cp "$am_depcomp" conftest.dir
> 
> It works fine now with the cat.

  Hm, that sounds like a file that you have write but not delete permissions
to.
 
> Can someone look into this please,

  Well, just to state the obvious, /you/ would be the most ideally-placed
person to do so.

  I don't even have Vista, so I'm kinda ruled out there, but I'd take a look
at the perms and ACLs of conftest.dir and the existing depcomp file in there,
using both 'getfacl' to show cygwin's view of the posix-style perms, and
'cacls' to compare with windoze's opinion.

  BTW, you didn't by any chance use winzip to unpack the tarball did you?


cheers,
  DaveK
-- 
Can't think of a witty .sigline today


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

RE: Line info causes GCC to bomb?

[Dave Korn]

On , Dave Korn  wrote:

[  Please try to snip rawquotes of email addresses from replies (or even
better, configure your mailer to snip em out), posting someone's address to
the list causes them to receive more spam. 
(http://cygwin.com/acronyms#PCYMTNQREAIYR)   ]

> This preprocessed input causes GCC (3.4.4) to segfault
> 
>   # 1 "test.c" 1
> 
>   int main () {
>  return 0;
>   }
> 
> ... and this doesn't:
> 
>   # 1 "test.c"
>   # 1 "test.c" 1
> 
>   int main () {
> return 0;
>   }

>>  I can't find that syntax described in the documentation, can point me at
>> it?

> It's indexed in cpp.info under, "linemarkers."

  Ah, found it.  Heh, so it's not documented in the section about "Line
control", it's implicitly documented in the output format section. 

> The output from cpp also contains other directives between the first two
> line markers, as in the second form, although I haven't had the opportunity
> to look at the gcc source to determine their purpose, or what
> initialization gcc needs for its line numbering.
> 
> If I can locate the relevant routines in gcc I might be able to provide a
> patch.  My own preprocessor already has the necessary compatibility fix,
> though untested, because my linux box is waiting for spare parts.

  It's an arguable case.  These pseudo-line-directives are part of
the internal interface between parts of the compiler and I think not really
intended for general consumption, even though it is described as "an
extension".  Since the form with the file introducer is what gcc generates,
and is what is guaranteed to work across all versions, I think you should
treat this situation as if there is a documentation error in the cpp manual,
and that it's part of the spec that you need to have an introducer line
before any lines with flags.   

  As for the sources, that's gcc-3.4.4/gcc/cpp*.[ch] for the most part.

cheers,
  DaveK
--
Can't think of a witty .sigline today
On 20 August 2007 12:26, g6522c wrote:


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: REAL Problem building GCC on Cygwin on Vista

[Aaron Gray]

On 19 August 2007 20:22, Aaron Gray wrote:

Now I having a problem with libcpp getting the error :-

   checking dependancy style of gcc... 
/usr/src/gcc-4.2.0/libcpp/configure: line 2887: ./depcomp: premission 
denied.


AFACT this actually looks like a Vista problem.

I replaced line 2875 with :-

   cat "$am_depcomp" > conftest.dir/depcomp

from

   cp "$am_depcomp" conftest.dir

It works fine now with the cat.

Can someone look into this please,

Aaron


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: python module patch

[Jason Tishler]

On Sun, Aug 19, 2007 at 11:46:27AM +0200, Reini Urban wrote:
> Yaakov (Cygwin Ports) schrieb:
> >Reini Urban wrote:
> >>extern __declspec(dllexport) cannot be used as constant during
> >>compile-time.
> >>=> "initializer element is not constant"
> >>cygwin auto-import feature get's that right at link-time.
> >>
> >>This is needed for the constant (compile-time) resolution of
> >>PyObject_HEAD_INIT(&PyType_Type) in a typical PyTypeObject struct.
> >
> >I believe the commonly accepted solution is to change this to
> >PyObject_HEAD_INIT(NULL) in the struct.
> >
> >http://starship.python.net/crew/mwh/toext/node20.html
> 
> Indeed. That sounds better.

FWIW, I concur too.

Jason

-- 
PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers
Fingerprint: 7A73 1405 7F2B E669 C19D  8784 1AFD E4CC ECF4 8EF6

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Default group shown by mkpasswd

[Saro Engels]

Currently I have installed cygwin on two xp professional machines which 
behave slightly different.
The problem is basically how to change my default group which is 
currently set in one machine to 513(None) and 547(Power Users) on the 
newer machine; as far as I found out yesterday, cygwin seems to have a 
special group whereas windows seems to ignore those.
It would be very very great if one could either point me to a package 
which gives commands equal groupmod/add/del or if you can point me to a 
some site changing this behaviour.

Thanks in advance
SE

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: cygwin compliation crash when uninstalling the old version of bash

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to wei on 8/19/2007 3:09 PM:
> Hi Eric
> 
> It's a popup box from setup.exe. I also attached the cygcheck.out in the
> email

And what did the popup say?  Nothing in your cygcheck output is jumping
out at me as unusual, but without knowing what the crash said, I don't
know the full picture.

- --
Don't work too hard, make some time for fun as well!

Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGyYQT84KuGfSFAYARAuZnAKDCdEeaC4EZMnY5LYZzq6oONIRvyQCdEuaF
cd5ZAyq6VoAJ2DRZOzxtcNs=
=6zGw
-END PGP SIGNATURE-

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Line info causes GCC to bomb?

[Brian Dessent]

[EMAIL PROTECTED] wrote:

> If I can locate the relevant routines in gcc I might be able to provide a 
> patch.  My 

I wouldn't spend too much effort on that.  It's fixed in 4.x, and the
3.x branches were closed a long time ago.  OTOH, it might be nice to
have this fixed in the Cygwin-distributed gcc; however since it seems to
be a rather esoteric corner case it's not a huge priority.

Brian

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

RE: Line info causes GCC to bomb?

[g6522c]

-Original Message-
>From: Dave Korn <[EMAIL PROTECTED]>
>Sent: Aug 20, 2007 6:25 AM
>To: [EMAIL PROTECTED]
>Cc: cygwin@cygwin.com
>Subject: RE: Line info causes GCC to bomb?
>
>On 20 August 2007 10:54, g6522c wrote:
>
>[  List Cc'd back in.  http://cygwin.com/acronyms#PPIOSPE, thanks!  ]
>
 This preprocessed input causes GCC (3.4.4) to segfault
 
   # 1 "test.c" 1
 
   int main () {
  return 0;
   }
 
 ... and this doesn't:
 
   # 1 "test.c"
   # 1 "test.c" 1
 
   int main () {
 return 0;
   }
>
>> This is from a different front end that I've put together.  It's referred
>> to in the sig line.  The line numbering is as documented - partially - in
>> the cpp Texinfo manual.  The input seems to be valid for all other builds
>> of GCC.   
>
>  I can't find that syntax described in the documentation, can point me at it?
>
>  I note that gcc doesn't generate code like your first form, it always does 
> it the second way, which makes me think that the first #-directive, the one 
> without the trailing number, acts as some kind of introducer or otherwise 
> triggers some internal struct to be set up in cpp without which the second 
> form, with the trailing number, is invalid.
>
>
>cheers,
>  DaveK

It's indexed in cpp.info under, "linemarkers."  

The output from cpp also contains other directives between the first two line 
markers, as in the second form, although I haven't had the opportunity to look 
at the gcc source to determine their purpose, or what initialization gcc needs 
for its line numbering.  

If I can locate the relevant routines in gcc I might be able to provide a 
patch.  My own preprocessor already has the necessary compatibility fix, though 
untested, because my linux box is waiting for spare parts.

Thanks again,

Robert



Ctalk Project Home Page: http://ctalk-lang.sourceforge.net
Mailing List:  [EMAIL PROTECTED]


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

RE: Copy/Paste doesn't run on Cygwin

[Jose Luis]

Here there is another link about this issue:

http://www.nabble.com/Serious-flaw-in-Cygwin-X-clipboard-integration-prevents-paste-from-X-to-Windows-apps-tf946678.html#a2458589


It seems that it is a Cygwin X bug. 

Does anybody know if there is a fix to this problem?

Regards,
Jose Luis.





Jose Luis wrote:
> 
> 
> Thanks for your help.
> 
> 
> I have tried it, but the problem persist.
> 
> I have found som information about this issue on a "Vim Forum":
> 
> http://www.nabble.com/Patch-for-problems-with-X11-GUI---XTERM-clipboard-integration-with-native-Win-applications---was-%22clipboard-support-with-GTK-GUI-under-cygwin%22-tf935831.html#a2424350
> 
> 
> Regards,
> Jose Luis
> 
> 
> 
> 
> Dave Korn wrote:
>> 
>> On 20 August 2007 10:26, Jose Luis wrote:
>> 
>>> Hi,
>>> 
>>> Without the ".vimrc" file the copy/paste runs fine in a vim's edited
>>> file,
>>> but when I copy the example vimrc file
>>> (/usr/share/vim/vim71/vimrc_example.vim) in $HOME/.vimrc, the selected
>>> text
>>> isn't copy automatically on the clipboard.
>> 
>>   When the behaviour of vim changes in the presence of a .vimrc file,
>> suspect something to do with the vi-compatible mode, which is disabled by
>> doing so.  Does adding '-C' to the command-line help?
>> 
>> 
>> cheers,
>>   DaveK
>> -- 
>> Can't think of a witty .sigline today
>> 
>> 
>> --
>> Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
>> Problem reports:   http://cygwin.com/problems.html
>> Documentation: http://cygwin.com/docs.html
>> FAQ:   http://cygwin.com/faq/
>> 
>> 
>> 
> 
> 

-- 
View this message in context: 
http://www.nabble.com/Copy-Paste-doesn%27t-run-on-Cygwin-tf4297657.html#a12233534
Sent from the Cygwin Users mailing list archive at Nabble.com.


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

RE: Line info causes GCC to bomb?

[Dave Korn]

On 20 August 2007 10:54, g6522c wrote:

[  List Cc'd back in.  http://cygwin.com/acronyms#PPIOSPE, thanks!  ]

>>> This preprocessed input causes GCC (3.4.4) to segfault
>>> 
>>>   # 1 "test.c" 1
>>> 
>>>   int main () {
>>>  return 0;
>>>   }
>>> 
>>> ... and this doesn't:
>>> 
>>>   # 1 "test.c"
>>>   # 1 "test.c" 1
>>> 
>>>   int main () {
>>> return 0;
>>>   }

> This is from a different front end that I've put together.  It's referred
> to in the sig line.  The line numbering is as documented - partially - in
> the cpp Texinfo manual.  The input seems to be valid for all other builds
> of GCC.   

  I can't find that syntax described in the documentation, can point me at it?

  I note that gcc doesn't generate code like your first form, it always does it 
the second way, which makes me think that the first #-directive, the one 
without the trailing number, acts as some kind of introducer or otherwise 
triggers some internal struct to be set up in cpp without which the second 
form, with the trailing number, is invalid.


cheers,
  DaveK
-- 
Can't think of a witty .sigline today


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

RE: Copy/Paste doesn't run on Cygwin

[Jose Luis]

Thanks for your help.


I have tried it, but the problem persist.

I have found som information about this issue on a "Vim Forum":

http://www.nabble.com/Patch-for-problems-with-X11-GUI---XTERM-clipboard-integration-with-native-Win-applications---was-%22clipboard-support-with-GTK-GUI-under-cygwin%22-tf935831.html#a2424350


Regards,
Jose Luis




Dave Korn wrote:
> 
> On 20 August 2007 10:26, Jose Luis wrote:
> 
>> Hi,
>> 
>> Without the ".vimrc" file the copy/paste runs fine in a vim's edited
>> file,
>> but when I copy the example vimrc file
>> (/usr/share/vim/vim71/vimrc_example.vim) in $HOME/.vimrc, the selected
>> text
>> isn't copy automatically on the clipboard.
> 
>   When the behaviour of vim changes in the presence of a .vimrc file,
> suspect something to do with the vi-compatible mode, which is disabled by
> doing so.  Does adding '-C' to the command-line help?
> 
> 
> cheers,
>   DaveK
> -- 
> Can't think of a witty .sigline today
> 
> 
> --
> Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
> Problem reports:   http://cygwin.com/problems.html
> Documentation: http://cygwin.com/docs.html
> FAQ:   http://cygwin.com/faq/
> 
> 
> 

-- 
View this message in context: 
http://www.nabble.com/Copy-Paste-doesn%27t-run-on-Cygwin-tf4297657.html#a12233308
Sent from the Cygwin Users mailing list archive at Nabble.com.


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Fw: clear

[Brian Dessent]

[EMAIL PROTECTED] wrote:

> However, neither of these packages in available in Setup.exe. Only
> libncurses libraries are available, and they are already installed on my
> computer.

They are available in setup.  Set the view to Full for a flat list.  If
they're still not listed, then there must be something wrong with the
mirror site that you've chosen.

Brian

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

RE: Copy/Paste doesn't run on Cygwin

[Dave Korn]

On 20 August 2007 10:26, Jose Luis wrote:

> Hi,
> 
> Without the ".vimrc" file the copy/paste runs fine in a vim's edited file,
> but when I copy the example vimrc file
> (/usr/share/vim/vim71/vimrc_example.vim) in $HOME/.vimrc, the selected text
> isn't copy automatically on the clipboard.

  When the behaviour of vim changes in the presence of a .vimrc file, suspect 
something to do with the vi-compatible mode, which is disabled by doing so.  
Does adding '-C' to the command-line help?


cheers,
  DaveK
-- 
Can't think of a witty .sigline today


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Fw: clear

[PDeRochambeau]

Hello,

when you search for "ncurses" in the Cygwin Package List of the cygwin.com 
website, two ncurses packages appear:

- ncurses-5.5-2
- ncurses-5.5-3

However, neither of these packages in available in Setup.exe. Only 
libncurses libraries are available, and they are already installed on my 
computer.

Philippe








Brian Dessent <[EMAIL PROTECTED]> 
Sent by: [EMAIL PROTECTED]
08/20/2007 11:48 AM
Please respond to
cygwin@cygwin.com


To
cygwin@cygwin.com
cc

Subject
Re: Fw: clear






[EMAIL PROTECTED] wrote:

> In Cygwin Package List, it says that clear was removed and that ncurses
> should be used instead (?). However, libncurses7 and libncurses8 ARE
> installed on my machine, according to setup.exe, which means, I guess,
> that ncurses is installed.

No, it means that libncurses is installed.  There is also a 'ncurses'
package, and that is what contains the clear command.  (You can look
this up yourself using the Package Search page.)

The reasoning for why packages are split like this has many reasons. 
For one thing, it allows library versioning, where you have multiple
packages compiled against multiple versions of the library.  For
another, it allows installing just the binary runtime components of a
library, without pulling in all the other nonessential parts just
because the user happened to have installed a package that is linked
against that library.  And that is just what has happened in this case.

Brian

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/




--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

RE: Permission denied problem

[Marko Loparic]

On 17 August 2007 17:35, Dave Korn

>  For comparison, what does the standard windows 'cacls.exe' utility tell you
> about that directory, and about one where the problem doesn't happen?

cacls will certainly be of great help, thanks a lot. Here is what I
get for the directory without problems:

$ cacls 'x:\02_0024\PPP'
x:\02_0024\PPP NT AUTHORITY\SYSTEM:(OI)(CI)F
 CORP\AllShareAdminGroup:(OI)(CI)F
 CORP\AllShareListGroup:(CI)R
 CORP\13.G__Access_Admin:R
 CORP\13.G__R_D_ITS:R
 CORP\13.G__Spark_International:R
 CORP\13.G__Team_Access_Admin:R
 CORP\16.0024_MO_Access_Admin:R
 CORP\13.G__Assistant:R
 CORP\13.G__Team_External:R
 CORP\13.G__Team_Member:R

And here is the directory with the permission denied problem

$ cacls 'x:\02_0024\PPP\QQQ'
x:\02_0024\PPP\QQQ CORP\13.G__Mgmt_Team:(DENY)(special access:)
DELETE
SYNCHRONIZE

 CORP\13.G__R_D_ITS:(DENY)(special access:)
  DELETE
  SYNCHRONIZE

 CORP\13.G__R_D_Restricted:(DENY)(special access:)
 DELETE
 SYNCHRONIZE

 CORP\13.G__RALM_Restricted:(DENY)(special access:)
  DELETE
  SYNCHRONIZE

 CORP\13.G__SCS_Restricted:(DENY)(special access:)
 DELETE
 SYNCHRONIZE

 CORP\13.G__Team_External:(DENY)(special access:)
DELETE
SYNCHRONIZE

 NT AUTHORITY\SYSTEM:(OI)(CI)F
 CORP\AllShareAdminGroup:(OI)(CI)F
 CORP\AllShareListGroup:(CI)R
 CORP\13.G__Access_Admin:(CI)R
 CORP\13.G__Team_Access_Admin:(CI)R
 CORP\16.0024_MO_Access_Admin:(CI)R
 CORP\13.G__Mgmt_Team:(OI)(CI)(special access:)
DELETE
READ_CONTROL
SYNCHRONIZE
FILE_GENERIC_WRITE
FILE_WRITE_DATA
FILE_APPEND_DATA
FILE_WRITE_EA
FILE_WRITE_ATTRIBUTES

 CORP\13.G__R_D_ITS:(OI)(CI)C
 CORP\13.G__R_D_Restricted:(OI)(CI)(special access:)
 DELETE
 READ_CONTROL
 SYNCHRONIZE
 FILE_GENERIC_WRITE
 FILE_WRITE_DATA
 FILE_APPEND_DATA
 FILE_WRITE_EA
 FILE_WRITE_ATTRIBUTES

 CORP\13.G__RALM_Restricted:(OI)(CI)(special access:)
  DELETE
  READ_CONTROL
  SYNCHRONIZE
  FILE_GENERIC_WRITE
  FILE_WRITE_DATA
  FILE_APPEND_DATA
  FILE_WRITE_EA
  FILE_WRITE_ATTRIBUTES

 CORP\13.G__SCS_Restricted:(OI)(CI)(special access:)
 DELETE
 READ_CONTROL
 SYNCHRONIZE
 FILE_GENERIC_WRITE
 FILE_WRITE_DATA
 FILE_APPEND_DATA
 FILE_WRITE_EA
 FILE_WRITE_ATTRIBUTES

 CORP\13.G__Team_External:(OI)(CI)C
 CORP\13.G__Team_Member:(OI)(CI)(special access:)
  READ_CONTROL
  WRITE_DAC
  WRITE_OWNER
  SYNCHRONIZE
  FILE_GENERIC_READ
  FILE_GENERIC_WRITE
  FILE_GENERIC_EXECUTE
  FILE_READ_DATA
  FILE_WRITE_DATA
  FILE_APPEND_DATA
  FILE_READ_EA
  FILE_WRITE_EA
  FILE_EXECUTE
  FILE_DELETE_CHILD

Re: Fw: clear

[Brian Dessent]

[EMAIL PROTECTED] wrote:

> In Cygwin Package List, it says that clear was removed and that ncurses
> should be used instead (?). However, libncurses7 and libncurses8 ARE
> installed on my machine, according to setup.exe, which means, I guess,
> that ncurses is installed.

No, it means that libncurses is installed.  There is also a 'ncurses'
package, and that is what contains the clear command.  (You can look
this up yourself using the Package Search page.)

The reasoning for why packages are split like this has many reasons. 
For one thing, it allows library versioning, where you have multiple
packages compiled against multiple versions of the library.  For
another, it allows installing just the binary runtime components of a
library, without pulling in all the other nonessential parts just
because the user happened to have installed a package that is linked
against that library.  And that is just what has happened in this case.

Brian

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

RE: clear

[Dave Korn]

On 20 August 2007 10:30, [EMAIL PROTECTED] wrote:

> Hello,
> 
> I have just reinstalled cygwin from scratch (deleted c:\cygwin directory)
> and noticed that the clear command was not in /usr/bin anymore.
> 
> In Cygwin Package List, it says that clear was removed and that ncurses
> should be used instead (?). However, libncurses7 and libncurses8 ARE
> installed on my machine, according to setup.exe, which means, I guess,
> that ncurses is installed.
> 
> How do you use ncurses "clear" command, if there is such a thing?

  I dunno, but here's a couple of alternatives:

alias clear='cmd /c cls'
alias clear='echo -e "\033c"'

  The cmd.exe-based one works best in a cygwin DOS-console shell, the echo
version works best in a proper console like rxvt/xterm.

cheers,
  DaveK
-- 
Can't think of a witty .sigline today


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: rsync problems from Vista installed cygwin, ok on XP

[DaveB]

Corinna Vinschen-2 wrote:
> 
> On Aug 18 21:06, DaveB wrote:
>> So... two interesting followon points...
>> 
>> 1. Why didn't the ACLs get set to something reasonable as opposed to 000
>> in
>> the first place when I created this little test area in Vista?  After
>> all, I
> 
> The directory has been created using native Windows tools.  The
> permissions
> given using native Windows tools *are* strange and don't follow POSIX
> rules.
> It's perfectly valid that you can access a directory under Windows but get
> 000 POSIX permissions.  You did see the '+' at the end of the permission
> in ls -l?
> 

OK, I now see this + and had no idea what it meant... but have now found the
doc in cygwin by typing "info ls", where it says...

 Following the file mode bits is a single character that specifies
 whether an alternate access method such as an access control list
 applies to the file.  When the character following the file mode
 bits is a space, there is no alternate access method.  When it is
 a printing character, then there is such a method.

 For a file with an extended access control list, a `+' character is
 listed.  Basic access control lists are equivalent to the
 permissions listed, and are not considered an alternate access
 method.

Interesting.  So if it knows there is an ACL which overrides the --
permissions that were inherited from C:\ then why can't the cygwin port of
rsync allow a Windows-friendly option for rsync'ing these files... even if
it cannot directly read the ACL maybe it could allow you to invoke some
special rsync permissions sync'ing flag?

I looked in the man rsync doc, and found some flags that might be helpful
... namely  -p -E and --chmod.  But even chmod=XXX doesn't quite let you do
automatically what would make sense, which is to create rsync'd files with
rwx for the exe's and rw for the others.

Not sure what the best way out of here is...??? I'm beginning to understand
this a bit better, but it sure is a minefield... will generate ongoing
problems for innocent future users.

PS Can anyone point to a good article on ACL that explains the relationship
to these ls -l permissions also?


-- 
View this message in context: 
http://www.nabble.com/rsync-problems-from-Vista-installed-cygwin%2C-ok-on-XP-tf4260918.html#a12232786
Sent from the Cygwin Users mailing list archive at Nabble.com.


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Fw: clear

[PDeRochambeau]

Hello,

I have just reinstalled cygwin from scratch (deleted c:\cygwin directory) 
and noticed that the clear command was not in /usr/bin anymore.

In Cygwin Package List, it says that clear was removed and that ncurses 
should be used instead (?). However, libncurses7 and libncurses8 ARE 
installed on my machine, according to setup.exe, which means, I guess, 
that ncurses is installed.

How do you use ncurses "clear" command, if there is such a thing?

Many thanks.

Best regards,

Philippe


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Copy/Paste doesn't run on Cygwin

[Jose Luis]

Hi,

Without the ".vimrc" file the copy/paste runs fine in a vim's edited file,
but when I copy the example vimrc file
(/usr/share/vim/vim71/vimrc_example.vim) in $HOME/.vimrc, the selected text
isn't copy automatically on the clipboard.

The ".vimrc" is attached.

http://www.nabble.com/file/p12232667/.vimrc .vimrc 

Some information about Cygwin is attached too. 

http://www.nabble.com/file/p12232667/cygcheck.out cygcheck.out 


The vim version is:

$ vim --version
VIM - Vi IMproved 7.1 (2007 May 12, compiled May 14 2007 16:29:51)
Compilado por [EMAIL PROTECTED]
Versión «enorme» sin GUI.  Aspectos incluidos (+) o no (-):
+arabic +autocmd -balloon_eval -browse ++builtin_terms +byte_offset +cindent
-clientserver -clipboard +cmdline_compl +cmdline_hist +cmdline_info
+comments
+cryptv +cscope +cursorshape +dialog_con +diff +digraphs -dnd -ebcdic
+emacs_tags +eval +ex_extra +extra_search +farsi +file_in_path +find_in_path
+folding -footer +fork() +gettext -hangul_input +iconv +insert_expand
+jumplist
 +keymap +langmap +libcall +linebreak +lispindent +listcmds +localmap +menu
+mksession +modify_fname +mouse -mouseshape +mouse_dec -mouse_gpm
-mouse_jsbterm +mouse_netterm +mouse_xterm +multi_byte +multi_lang -mzscheme
-netbeans_intg -osfiletype +path_extra -perl +postscript +printer +profile
-python +quickfix +reltime +rightleft -ruby +scrollbind +signs +smartindent
-sniff +statusline -sun_workshop +syntax +tag_binary +tag_old_static
-tag_any_white -tcl +terminfo +termresponse +textobjects +title -toolbar
+user_commands +vertsplit +virtualedit +visual +visualextra +viminfo
+vreplace
+wildignore +wildmenu +windows +writebackup -X11 -xfontset -xim -xsmp
-xterm_clipboard -xterm_save
 fichero «vimrc» del sistema: "$VIM/vimrc"
 fichero «vimrc» del usuario: "$HOME/.vimrc"
  fichero «exrc» del usuario: "$HOME/.exrc"
localización de $VIM: "/usr/share/vim"
Compilación: gcc -c -I. -Iproto -DHAVE_CONFIG_H -g -O2
Enlazado:
gcc   -L/usr/local/lib -o vim.exe   -lncurses  -liconv -lintl



Any help?


Thanks in advance,
Jose Luis


-- 
View this message in context: 
http://www.nabble.com/Copy-Paste-doesn%27t-run-on-Cygwin-tf4297657.html#a12232667
Sent from the Cygwin Users mailing list archive at Nabble.com.


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

RE: Problem with Text mounts after updating using setup.exe

[Bart van der Werf]

 
Could someone confirm this is introduced in grep-2.5.1a-4, grep-2.5.1a-2
seems to be good?

Greets, Bart


> -Original Message-
> From: Bart van der Werf
> Sent: Wednesday, August 15, 2007 10:44 AM
> To: cygwin@cygwin.com
> Subject: Problem with Text mounts after updating using setup.exe
> 
> After upgrading cygwin some of my textmode mount files 
> started to have additional 0x0d characters.
>  
> Example of problem.
>  
> With a file test.txt
>  
> $ od -t x1 test.txt
> 000 61 0d 0a 62 0d 0a 63 0d 0a
> 011
>  
> with dos style newlines.
>  
> $ grep a test.txt > test2.txt
>  
> If i invoke grep on this file, i get the problem that it 
> duplicates the 0x0d 
>  
> $ od -t x1 test2.txt
> 000 61 0d 0d 0a
> 004
>  
> I started getting this problem after running setup.exe this week.
>  
> The version of cygwin before the upgrade was atleast a year old.
>  
> What should i do ?
> Do i need to provide additional information ?
>  
> I wouldn't expect an additional 0x0d even if the mount was in binmode.
>  
> greeting Bart van der Werf
> 

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

RE: Line info causes GCC to bomb?

[Dave Korn]

On 19 August 2007 21:24, [EMAIL PROTECTED] wrote:

> I haven't seen this problem anywhere in the list archive, so
> here it is.
> 
> This preprocessed input causes GCC (3.4.4) to segfault
> 
>   # 1 "test.c" 1
> 
>   int main () {
>  return 0;
>   }
> 
> ... and this doesn't:
> 
>   # 1 "test.c"
>   # 1 "test.c" 1
> 
>   int main () {
> return 0;
>   }
> 
> Am I missing something?

  Nope, I can reproduce it.  

  Was it you or gcc that generated that preprocessed file?  It obviously 
shouldn't crash, but it's a much higher priority if gcc itself generates 
invalid preprocessed output than if it gets confused by something you've 
hand-generated (or post-pre-processed!) yourself.

cheers,
  DaveK
-- 
Can't think of a witty .sigline today


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: RXVT doesn't recognize ALT + Cursor keys

[Corinna Vinschen]

On Aug 19 13:55, Andrew DeFaria wrote:
> I understand, however even as a vi user you use the "j" and "k" keys for 
> up and down movement, the "h" and "l" keys for left and right movement 
> and the "w" for word forward forward, "b" for word back no? I've always 
> heard that the reason for that is to more efficiently do movement while 
> leaving your fingers on the "home row". If that's true then why then 
> reorient your hands off home row to do word movement just for the 
> command line? Just something to think about...

Habit?


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  cygwin AT cygwin DOT com
Red Hat

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

[ANNOUNCEMENT] Updated: Unicode text editor mined 2000 release 14

[Thomas Wolff]

 mined 2000 release 14
  (July 2007)

Mined is a powerful text editor with a comprehensive yet concise and 
easy-to-use user interface supporting modern interaction paradigms, 
and fast, small-footprint behaviour.

Mined provides both extensive Unicode and CJK support offering many 
specific features and covering special cases that other editors 
are not aware of (like auto-detection features and automatic handling 
of terminal variations, or Han character information).
It was the first editor that supported Unicode in a plain-text terminal 
(like xterm or rxvt).

Basically, mined is an editor tailored to reliable and efficient 
editing of plain text documents and programs, with features and 
interactive behaviour designed for this purpose.


Following:
* Hints and links
* Major enhancements in this release
* Mined Overview




To install mined on cygwin, run the cygwin setup program, 
in the "Select Packages" menu, open the "Editors" category and 
select the mined package.

More information (with screenshots, feature overview and change log) 
and download are available from the mined web site at
http://towo.net/mined/


Mined is co-hosted at sourceforge and has a mailing list 
which can be subscribed at





Major enhancements in this release:

Text editing features:
* Case-insensitive search (except when searching for an identifier).
* New command Alt-x toggles preceding character and its hexadecimal code.

Character encoding support enhancements:
* Additional option -E? just determines and displays text file encoding(s).
* Additional option +E? just determines and displays terminal encoding.
* Separated display of "isolated" combining characters (e.g. after TAB).
* Improved text encoding auto-detection:
  * Improved detection of CJK encodings vs. 8-bit encodings.
  * Added auto-detection of Windows-"ANSI" (CP1252), PC-Latin (CP850), MacRoman.
  * Improved configuration of auto-detection.

Character input enhancements:
* New shortcuts for input of plain quote marks (in smart quotes mode).

Interworking enhancements:
* Terminal encoding handling:
  * Added options -f / -F to indicate limited font coverage of special 
characters.
  * Detecting and handling non-Unicode terminal with Arabic ligature joining.
  * Detecting and handling special width behaviour of rxvt, mlterm, konsole 
  concerning unassigned characters, non-BMP, or non-Unicode characters.
  * Applying display replacement for illegal Unicode characters by default 
  (codes ending with FFFE/, surrogates, non-Unicode code points).
  * Fixed a lot of other remaining width display inconsistencies.
* Making use of window focus out/in reports (xterm 224).
* Workaround for xterm 224 bug which could lock up the terminal.
* Adjusting display details to properties of gnome-terminal, konsole.
* Considering termcap information of function key escape sequences.

Miscellaneous changes:
* Increased speed of some UTF-8 search operations by a factor of ~ 40.
* Colour highlighting of DOS/Mac line end indications.




Feature Overview

Good interactive features
* Intuitive user interface
* Logical and consistent concept of navigating and editing text 
  (without ancient line-end handling limitations or insert/append confusion)
* Supports various control styles:
  - Editing with command control, function key control, or menu control
  - Navigation by cursor keys, control keys, mouse or scrollbar
* Concise and comprehensive menus (driven by keyboard or mouse)
* "HOP" key paradigm doubles the number of navigation functions 
  that can be most easily reached and remembered by 
  intuitively amplifying the associated function
* Immediate adjustment if the window size is changed, in any 
  state of interaction

Versatile character encoding support
* Extensive Unicode support, including double-width and combining characters,
  script highlighting, 
  various methods of character input support 
  (mapped keyboard input methods, mnemonic and numeric input),
  supporting CJK, Vietnamese, Hebrew, Arabic, and other scripts
* Extensive accented character input support, including 
  multiple accent prefix keys.
* Support for Greek (monotonic and polytonic).
* Support for Cyrillic accented characters.
* Support of bidirectional terminals, Arabic ligature joining
* East Asian character set support: handling of major CJK encodings 
  (including GB18030 and full EUC-JP with combining characters)
* Support for a large number of 8 bit encodings 
  (with combining characters for Vietnamese, Thai, Arabic, Hebrew)
* Support of CJK input methods by enhanced keyboard 
  mapping including multiple choice mappings (handled by a pick list menu);
  c