Re: The C locale

[Andy Koppe]

Christopher Faylor:
>Andy Koppe:
>>Trying to reply to [banned]'s post about locale issues, I got
>>rather confused about the C locale. The manual and the POSIX standard
>>say that it supports ASCII only, so in theory anything above 0x7F
>>should be rejected. In practice though, both Cygwin 1.5 and 1.7 do
>>support characters above 0x7F in the C locale, which could be quite
>>useful. Trouble is, they do so rather inconsistenly.
>>
>>Both in 1.5 and 1.7, the mb conversion functions treat such characters
>>as ISO-8859-1. In other words, conversion between chars and wchars are
>>simple casts (except that wchars above 0xFF can't be converted). This
>>makes some sense.
>>
>>Filename handling is different though. Cygwin 1.5 translates filenames
>>according to the system's ANSI codepage. I guess the inconsistency
>>with the mb functions didn't really matter, as the mb functions were
>>pretty much useless anyway, and supporting the system codepage was
>>more important.
>>
>>So, with Cygwin 1.7, I'd have expected filename handling in the C
>>locale to either use ISO-8859-1 for consistency with the mb functions,
>>or the ANSI codepage for compatibility with 1.5. In actual fact
>>though, it uses UTF-8.
>>
>>Is this on purpose? If so, shouldn't the multibyte conversions
>>functions in the C locale use UTF-8 as well?
>
>Since Cygwin has a clear system that it is supposed to be emulating,
>the real question is "What does Linux do?"

Tried it on Debian and Suse: the multibyte conversion functions are
strict ASCII, i.e. anything
beyond 0x7F is considered an encoding error.

POSIX requires that ASCII is supported in the C locale, but does not
actually outlaw ASCII-compatible extensions beyond that.

Locales don't affect filenames on Linux, i.e. any sequence of bytes
passed to open() goes straight to disk (except for the path
separator). This effectively means that filenames are encoded in
whatever charset happened to be active at the time the file was
created. Hence anyone accessing it with a different charset setting
will get gibberish.

POSIX is impressively unhelpful on the topic of filenames. All it
guarantees for filenames is the "portable filename character set":
ASCII letters and digits, plus the hyphen, dot, and underscore.

So altogether we've got no fewer than four choices here:
- strict ASCII (as with Linux mb functions)
- ISO-8859-1 (as with newlib mb functions)
- Default Windows ANSI/OEM codepage (as with Cygwin 1.5 filenames)
- UTF-8 (as with Cygwin 1.7 filenames)

In Cygwin 1.5, both file operations and the console use the default
Windows codepage, which often contains all the characters a user cares
about. If you set up readline for 8-bit I/O and change the console
font to something useful, this works reasonably well, including
Cygwin-created filenames showing up correctly in Explorer.

A rather important exception is 'ls', which seems to have its own
hardcoded limitation to 7 bits for the C locale: anything non-ASCII is
shown as '? there'. Things do work correctly elsewhere though, e.g. in
bash tab completion or Midnight Commander.

A user with such a setup who upgrades to 1.7 will find that things
will no longer work as before, since filenames are translated to UTF-8
whereas the console now seems to use ISO-8859-1 (presumably via the mb
functions) by default. Hence a file called 'bäh' in Explorer (with
a-umlaut in the middle), will show as 'bäh' instead.

And if you try to create 'bäh' in Cygwin 1.7, you actually get a file
called 'b', because the 'ä' (0xE4) in ISO-8859-1 turns into an
encoding error when interpreted as UTF-8, and the name simply seems to
be truncated at that point.

I see two good solutions:
- Use the default Windows codepage for filenames, console, and
multibyte functions. This is what happens already if you specifiy a
locale with a language but no charset, e.g. "en". Maximum 1.5
compatibility.
- Use UTF-8 throughout. Full Unicode support out-of-the box.

And a cheap'n'nasty one:
- Restrict the multibyte functions and console to 7-bit ASCII. Still
means it's inconsistent with the filename conversions, but at least
non-ASCII characters wouldn't show up wrongly. Instead, they wouldn't
show at all.

Andy

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

Re: GNU screen hangs

[Andrew DeFaria]

Mark J. Reed wrote:

Andrew DeFaria wrote:

Excuse me, I'm off to the tongue tanning salon... Â ;-)
Crazy Americans! Tanning one end while bleaching the other! What's 
going on in this country?!

Here in America we treat both black and white equally! ;-)

Now what was I supposed to be bleaching again...
--
Andrew DeFaria 
Can fat people go skinny-dipping?


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

Re: struct dirent.d_reclen

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Eric Blake on 9/1/2009 7:10 PM:
> According to Christopher Faylor on 9/1/2009 5:37 PM:
>> Maybe you mean d_namlen?
> 
> Yes; serves me right for confusing readdir(2) and readdir(3) man pages.

Actually, it looks like Linux has only d_reclen (and that d_namlen is a
documentation bug):

http://www.kernel.org/doc/man-pages/online/pages/man3/readdir.3.html

and that Linus prefers d_reclen over d_namlen from the kernel side of
things (where, in the Linux kernel, d_reclen is always aligned, such that
adjusting d_reclen by offsetof(struct dirent,d_name) can be larger than
strlen(d_name)):

http://lkml.indiana.edu/hypermail/linux/kernel/9506/0033.html

So Linux doesn't provide d_namlen, and coreutils can't optimize for known
lengths on Linux.  But BSD does:

http://www.gsp.com/cgi-bin/man.cgi?section=5&topic=dir

At any rate, coreutils uses a macro _D_EXACT_NAMELEN(dirent), which
evaluates to either d_namlen, a calculation on d_reclen (if d_reclen is
accurate enough*), or a call to strlen() if all else fails; so that it is
portable to whichever the underlying semantics happen to be.

* If d_reclen minimally rounds up to an aligned size, for example if it is
only at most 8 bytes larger than strlen(d_name), then it is still faster
to do a strchr(,0)-d_name from a starting point 8 bytes before where
d_reclen says the record ends, rather than strlen(d_name[0]).

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

Eric Blake e...@byu.net
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkqdzKQACgkQ84KuGfSFAYBtsQCgvYcI8Y7CLJOYxPKIySgwCpJn
dvAAoIVO47y0+F24lGktxBAF6gbj0rlh
=Zctr
-END PGP SIGNATURE-

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

Re: struct dirent.d_reclen

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Christopher Faylor on 9/1/2009 5:37 PM:
> Maybe you mean d_namlen?

Yes; serves me right for confusing readdir(2) and readdir(3) man pages.

> It is not a given that adding d_reclen would speed anything up since it
> cause every single program that uses dirent to effectively perform a
> strlen on every record returned by readdir whether it needed that field
> or not.

Not so.  For example, fhandler_disk_file::readdir_helper is already doing
a sys_wcstombs to populate the d_name buffer, and that returns the length
as a side effect.  In other words, the cost of providing the length to the
client is an O(1) single assignment of an already-existing value per entry
(and when you consider that we are already assigning __d_unused1 to 0,
that means no net increase in cost to clients that don't care about the
length); whereas the current situation requires clients that care about
the length to use O(n) strlen() and duplicate something that was
previously calculated by cygwin1.dll.

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

Eric Blake e...@byu.net
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkqdxfwACgkQ84KuGfSFAYC25wCgukOyTo5JpQ5c1wMk2HhpcJtD
MrUAn2qUnrv2+w4SsGjf6BKzjawc6ndA
=q8gE
-END PGP SIGNATURE-

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

Re: std::arg() bug : not repetitive ?

[Dave Korn]

Angelo Graziosi wrote:
> Dave Korn wrote:
>> IIUC this is basically fixed in GCC
>> HEAD now and 4.5.0 shouldn't suffer the same problem.
> 
> Just for completeness...
> 
> With 4.5-20090827 snapshot, it does:
> 
> $ g++-4.5 arg_bug.cpp -o0 -o arg_bug
> 
> $ ./arg_bug.exe
> 0.785398
> 0.785398
> 1
> -3.06287e-17

  Thanks for checking up on this.  It's possible we might need to add some
kind of fpu mode init to the CRT.  On the other hand, comment #127 in the PR
suggests to me that maybe we need to use the new command-line flag.  Hang on a
minute... "-fexcess-precision=standard" works only for C and ObjC.

> $ g++-4 comp_2.cc -o0 -o comp_2 -I /usr/include/octave-3.2.0/octave
> 
> $ ./comp_2.exe
> 0.785398
> 0.785398
> 1
> -3.06287e-17
> 
> $ g++-4 comp_2.cc -o0 -o comp_2 -I /usr/include/octave-3.2.0/octave 
> -fexcess-pr
> ecision=standard
> cc1plus: sorry, unimplemented: -fexcess-precision=standard for C++
> 
> $ 

  Bah.  Still, at least the -ffloat-store workaround still helps, for this
case at any rate.  Also, if you get GCC to use SSE instructions, there's no
issue with excess precision:

> $ g++-4 comp_2.cc -o0 -o comp_2 -I /usr/include/octave-3.2.0/octave 
> -march=pent
> ium4 -msse -mfpmath=sse
> 
> $ ./comp_2.exe
> 0.785398
> 0.785398
> 0
> 0
> 
> $

  However it does look like it's not going to get fully fixed for C++ until
someone with some serious language-lawyering skills can spend some time
defining the exact semantics.

cheers,
  DaveK


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

Re: How to install QT in CYGWIN

[Pok Wilson]

On 25/08/2009 11:19, Larry Hall (Cygwin) wrote: 
On 08/25/2009 04:28 AM, Pok Wilson wrote: 
>I am intending to use QT4.5.3 to create my GUI. 
4.5.3? The latest upstream release is 4.5.2.
        Sorry my mistake, you're right its QT 4.5.2.


I'm no QT expert (and I actually haven't even touched it in years) but
>from what I can see, only QT3 is available as part of the release.
>
Correct.


> 
I did manage to get Qt4 working some time ago. Cygwin Ports provides Qt 4.4.3 
for Cygwin 1.5 and 4.5.2 for 1.7.
Not sure how far he got, since Cygwin Ports (cygwinports.dotsrc.org)
>isn't accessible to me at the moment. So perhaps there is a QT4
>
> floating around for Cygwin 1.5.x on that site. If not, 
you'd have to build it yourself. 
SunSITE stopped their project hosting some time ago; Ports' new home is: 
http://cygwinports.org/
            I went to the cygwinports website. As I am quite new to this, I 
dont really understand what to do. There are some steps to follow.

1.     Use the current Cygwin setup.exe. 
2.     Launch setup.exe, and Download Without Installing from your 
favourite Cygwin mirror as normal. 
3.     Launch setup.exe again with the -X flag and choose Download 
Without Installing. 
4.     Add and select ftp://sourceware.org/pub/cygwinports (or a 
sourceware mirror) in the mirror list. 
5.     Select the packages of your choice and their dependencies and 
updates for download. 
6.     From a Cygwin shell, run this command: 
    sed -i -e "/^setup-timestamp:/ s/ \(.*\)/ $(date +%s)/" \
    "$(cygpath -u "$(cat 
/etc/setup/last-cache)")/ftp%3a%2f%2fsourceware.org%2fpub%2fcygwinports/setup.ini"
7. Launch setup.exe once more and Install from Local Directory. 
    I'm stuck at point number 3. How do i lauch setup again with the -X flag?
 
    So is it after following this steps i can install QT4 in Cygwin? If it is 
possible, can someone who has done this before provide a step-by step 
instructions on     exactly what i must do?

Yaakov
Cygwin Ports
 
I'm just curious that nowadays applications are all GUI.. I was thinking many 
people will be facing this same issue as me.. How do you guys compile GUI 
application in Cygwin?

Please note that Ports packages are supported on their own mailing list.


And to answer the inevitable question: I can't ITP this yet because there are a 
number of dependencies still missing from the distro.

            Where can I still get QT 3 if QT 4 fails?

> There is this message from Yaakov a while back about QT4: 



  New Email names for you! 
Get the Email name you've always wanted on the new @ymail and @rocketmail. 
Hurry before someone else does!
http://mail.promotions.yahoo.com/newdomains/sg/

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

Re: struct dirent.d_reclen

[Christopher Faylor]

On Tue, Sep 01, 2009 at 05:39:02PM +, Eric Blake wrote:
>Wish list (probably post 7.1): As long as we are making struct dirent more 
>like 
>Linux with the recent addition of d_type, we should probably also burn two of 
>the remaining 3 __d_unused1 bytes to declare unsigned short d_reclen, whose 
>value is always strlen(d_name), so that applications could get by with fewer 
>strlen calls.  Coreutils ls would certainly benefit from this optimization.

Defining d_*rec*len as strlen(d_name) would not be correct since that is
supposed to be the length of the record not the name.  That's why linux
has macros that look like this:

#  define _D_ALLOC_NAMLEN(d) (((char *) (d) + (d)->d_reclen) - &(d)->d_name[0])

Maybe you mean d_namlen?

It is not a given that adding d_reclen would speed anything up since it
cause every single program that uses dirent to effectively perform a
strlen on every record returned by readdir whether it needed that field
or not.  Making sure that field was filled out would also complicate
Cygwin's internal logic.

cgf

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

Re: std::arg() bug : not repetitive ?

[Angelo Graziosi]

Dave Korn wrote:

IIUC this is basically fixed in GCC
HEAD now and 4.5.0 shouldn't suffer the same problem.


Just for completeness...

With 4.5-20090827 snapshot, it does:

$ g++-4.5 arg_bug.cpp -o0 -o arg_bug

$ ./arg_bug.exe
0.785398
0.785398
1
-3.06287e-17

being (on 1.7):

$ g++-4.5 -v
Using built-in specs.
Target: i686-pc-cygwin
Configured with: /tmp/gcc-4.5-20090827/configure 
--prefix=/usr/local/gfortran --exec-prefix=/usr/local/gfortran 
--sysconfdir=/usr/local/gfortran/etc --libdir=/usr/local/gfortran/lib 
--libexecdir=/usr/local/gfortran/lib 
--mandir=/usr/local/gfortran/share/man 
--infodir=/usr/local/gfortran/share/info --program-suffix=-4.5 
--enable-bootstrap --enable-checking=release --enable-decimal-float=bid 
--enable-languages=c,c++,fortran --enable-libgomp --enable-libssp 
--enable-nls --enable-threads=posix 
--enable-version-specific-runtime-libs --disable-fixed-point 
--disable-libmudflap --disable-shared --disable-sjlj-exceptions 
--disable-win32-registry --with-arch=i686 --with-dwarf2 
--with-system-zlib --with-tune=generic --without-included-gettext 
--without-x

Thread model: posix
gcc version 4.5.0 20090827 (experimental) (GCC)


Cheers,
Angelo.

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

Re: [ANNOUNCEMENT] Updated: screen, now with 256-color support!

[Andy Koppe]

> 'term screen-256color' sets TERM=screen-256color in the
> environment of programs running inside screen, hence any program or
> script that recognises "screen" but not "screen-256color" will no
> longer work as expected.

Btw, a different approach to enabling 256 colour support by default,
which doesn't suffer from the problem above and which wouldn't require
any faffing about with the TERM variable, would be to bump the
'colors' capability in the "xterm", "rxvt" and "screen" terminfo
entries from 8 to 256.

Unfortunately that's not without compatibility issues either though,
which affect remote connections. When connecting from Cygwin to a host
where those terminfo entries still say 8 colours, 256 colour support
would be lost again. Not really a problem though, more just a
limitation.

The other way round is slightly more problematic. When connecting from
another host to Cygwin, the other system's xterm, rxvt or screen might
not actually support 256-colour sequences. Yet the application running
on Cygwin would think that it did based on the local terminfo entry.
This would likely result in no colours at all.

Then again, with the 256 colour codes having been around for quite a
long time, and Cygwin not exactly being a popular server platform,
this scenario seems rather unlikely.

(The underlying issue here is that the whole $TERM/termcap/terminfo
design is fundamentally broken. The sensible thing to do would be for
applications to directly ask the terminal they're actually connected
to about its capabilities, rather than consult a humungous local
database of mostly long-forgotten terminal types that's pretty much
guaranteed to be out-of-date.)

Andy

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

Re: [ANNOUNCEMENT] Updated: screen, now with 256-color support!

[Andrew Schulman]

> > You're talking about setting e.g. TERM=xterm-256color in the environment by
> > default, but I was asking whether it would cause any harm to put 'term
> > screen-256color' into the default /etc/screenrc.  Know any reason that I
> > shouldn't?
> 
> Well, yes. 'term screen-256color' sets TERM=screen-256color in the
> environment of programs running inside screen, hence any program or
> script that recognises "screen" but not "screen-256color" will no
> longer work as expected.
> 
> Furthermore, 'term screen-256color' (or '-T screen-256color') does not
> activate 256-color mode in screen. It it screen querying terminfo and
> finding that it is itself running in a 256-color terminal that does
> that.
> 
> Hence, when screen is started with the usual TERM setting of "xterm"
> or "rxvt", you'd end up telling programs running inside screen that
> 256 colors are available when that isn't actually the case.

Got it.  Thanks.
Andrew.

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

Re: [ANNOUNCEMENT] Updated: screen, now with 256-color support!

[Andy Koppe]

Andrew Schulman:
 Instead of specifying -T screen-256color every time, one can just put
 'term screen-256color' into .screenrc.  I'll update the docs to show this
 when I make the release current.
>>>
>>> Is there any reason that I shouldn't put this command into the default
>>> /etc/screenrc file?
>>
>> 'fraid so. Prompted by this thread I wondered the same thing about
>> mintty: why not set TERM to "xterm-256color" by default?
>>
>> Answer: because /etc/termcap doesn't know about it, and other programs
>> that read the TERM variable might not recognise it either.
>> Furthermore, user startup scripts that compare TERM to "xterm" or
>> "screen" would break.
>
> You're talking about setting e.g. TERM=xterm-256color in the environment by
> default, but I was asking whether it would cause any harm to put 'term
> screen-256color' into the default /etc/screenrc.  Know any reason that I
> shouldn't?

Well, yes. 'term screen-256color' sets TERM=screen-256color in the
environment of programs running inside screen, hence any program or
script that recognises "screen" but not "screen-256color" will no
longer work as expected.

Furthermore, 'term screen-256color' (or '-T screen-256color') does not
activate 256-color mode in screen. It it screen querying terminfo and
finding that it is itself running in a 256-color terminal that does
that.

Hence, when screen is started with the usual TERM setting of "xterm"
or "rxvt", you'd end up telling programs running inside screen that
256 colors are available when that isn't actually the case.

Andy

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

Re: std::arg() bug : not repetitive ?

[Dave Korn]

Marco Atzeri wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323#c2
> 
> $g++-4 -ffloat-store  comp_2.cc -O3 -o comp_4
> 
> ./comp_4
> 0.785398
> 0.785398
> 0
> 0

  Ah, good, thanks for the diagnosis.  IIUC this is basically fixed in GCC
HEAD now and 4.5.0 shouldn't suffer the same problem.

cheers,
  DaveK

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

Re: std::arg() bug : not repetitive ?

[Marco Atzeri]

--- Mar 1/9/09, Dave Korn ha scritto:

> Da: Dave Korn 
> Oggetto: Re: std::arg()   bug : not repetitive ?
> A: cygwin cygwin.com
> Data: Martedì 1 settembre 2009, 19:14
> Marco Atzeri wrote:
> > Hi DaveK,
> > the following test case on complex numbers 
> > is producing, puzzling result on cygwin (both 1.5 and
> 1,7) 
> > with gcc-4.3.2 (and also 3.4.4), while working on
> other platform:
> > 
> > #include 
> > #include "oct-cmplx.h"
> > 
> > int main ()
> > {
> >   Complex z1 (1.0, 1.0), z2 (1.0,
> 1.0);
> >   std::cout << (arg(z1)) <<
> '\n';
> >   std::cout << (arg(z2)) <<
> '\n';
> >   std::cout <<
> (arg(z1) >   std::cout << (arg(z1)-arg(z2))
> << '\n';
> > }
> > 
> > 
> > $ g++-4 comp_2.cc -o0 -o comp_2
> > 
> > $ ./comp_2
> > 0.785398
> > 0.785398
> > 1
> > -3.06287e-17    <<-- arg(1+i) is lower
> then arg(1+i) !!
> > 
> > Using different complex numbers is also possible to
> get 
> > 
> >   arg(-1-i) bigger then arg(-1-i)
> > 
> > Any idea what could cause it ? newlib ?
> 
>   Or maybe it's PR323 (excess precision) in some
> aspect.  Don't know yet, I'll
> have to have a look into it.
> 
>     cheers,
>       DaveK
> 

Dave,
thanks for the hint,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323#c2

$g++-4 -ffloat-store  comp_2.cc -O3 -o comp_4

./comp_4
0.785398
0.785398
0
0

Regards
Marco






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

Re: GNU screen hangs

[Mark J. Reed]

Andrew DeFaria wrote:
> Excuse me, I'm off to the tongue tanning salon...  ;-)

Crazy Americans!  Tanning one end while bleaching the other!  What's
going on in this country?!

-- 
Mark J. Reed 

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

struct dirent.d_reclen

[Eric Blake]

Wish list (probably post 7.1): As long as we are making struct dirent more like 
Linux with the recent addition of d_type, we should probably also burn two of 
the remaining 3 __d_unused1 bytes to declare unsigned short d_reclen, whose 
value is always strlen(d_name), so that applications could get by with fewer 
strlen calls.  Coreutils ls would certainly benefit from this optimization.

P.S. This is an interesting thread related to struct dirent - it shows that for 
once, cygwin is doing something more POSIX-y than Linux (ie. POSIX 2008 added a 
requirement that readdir d_ino always match stat st_ino, even for mount 
points), and therefore Cygwin actually gets to benefit from a coreutils 
optimization when Linux doesn't!

http://lists.gnu.org/archive/html/bug-coreutils/2009-08/msg00320.html
http://lists.gnu.org/archive/html/bug-coreutils/2009-08/msg00331.html
http://marc.info/?l=linux-kernel&m=125181054102075

-- 
Eric Blake



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

Re: std::arg() bug : not repetitive ?

[Dave Korn]

Marco Atzeri wrote:
> Hi DaveK,
> the following test case on complex numbers 
> is producing, puzzling result on cygwin (both 1.5 and 1,7) 
> with gcc-4.3.2 (and also 3.4.4), while working on other platform:
> 
> #include 
> #include "oct-cmplx.h"
> 
> int main ()
> {
>   Complex z1 (1.0, 1.0), z2 (1.0, 1.0);
>   std::cout << (arg(z1)) << '\n';
>   std::cout << (arg(z2)) << '\n';
>   std::cout << (arg(z1)   std::cout << (arg(z1)-arg(z2)) << '\n';
> }
> 
> 
> $ g++-4 comp_2.cc -o0 -o comp_2
> 
> $ ./comp_2
> 0.785398
> 0.785398
> 1
> -3.06287e-17<<-- arg(1+i) is lower then arg(1+i) !!
> 
> Using different complex numbers is also possible to get 
> 
>   arg(-1-i) bigger then arg(-1-i)
> 
> Any idea what could cause it ? newlib ?

  Or maybe it's PR323 (excess precision) in some aspect.  Don't know yet, I'll
have to have a look into it.

cheers,
  DaveK


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

Re: GNU screen hangs

[Dave Korn]

Christopher Faylor wrote:
> On Tue, Sep 01, 2009 at 07:12:51AM -0700, Andrew DeFaria wrote:
>> TV wrote:
>>> Oh, this is must be a cultural thing about americans and their tanned
>>> tongues.
>> Excuse me, I'm off to the tongue tanning salon...  ;-)
> 
> Ok.  I've got to stop drinking coffee while reading the cygwin list...

  Or wear noseplugs.

cheers,
  DaveK


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

Re: [ANNOUNCEMENT] Updated: screen, now with 256-color support!

[Andrew Schulman]

> Andrew Schulman:
> >> > TERM=xterm-256color screen -T screen-256color
> >>
> >> Instead of specifying -T screen-256color every time, one can just put
> >> 'term screen-256color' into .screenrc.  I'll update the docs to show this
> >> when I make the release current.
> >
> > Is there any reason that I shouldn't put this command into the default
> > /etc/screenrc file?
> 
> 'fraid so. Prompted by this thread I wondered the same thing about
> mintty: why not set TERM to "xterm-256color" by default?
> 
> Answer: because /etc/termcap doesn't know about it, and other programs
> that read the TERM variable might not recognise it either.
> Furthermore, user startup scripts that compare TERM to "xterm" or
> "screen" would break.

You're talking about setting e.g. TERM=xterm-256color in the environment by
default, but I was asking whether it would cause any harm to put 'term
screen-256color' into the default /etc/screenrc.  Know any reason that I
shouldn't?

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

Re: [ANNOUNCEMENT] Updated: screen, now with 256-color support!

[Andy Koppe]

Andrew Schulman:
>> > TERM=xterm-256color screen -T screen-256color
>>
>> Instead of specifying -T screen-256color every time, one can just put
>> 'term screen-256color' into .screenrc.  I'll update the docs to show this
>> when I make the release current.
>
> Is there any reason that I shouldn't put this command into the default
> /etc/screenrc file?

'fraid so. Prompted by this thread I wondered the same thing about
mintty: why not set TERM to "xterm-256color" by default?

Answer: because /etc/termcap doesn't know about it, and other programs
that read the TERM variable might not recognise it either.
Furthermore, user startup scripts that compare TERM to "xterm" or
"screen" would break.

Shame.

Andy

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

Re: [ANNOUNCEMENT] Updated: screen, now with 256-color support!

[Andrew Schulman]

> > TERM=xterm-256color screen -T screen-256color
> 
> Instead of specifying -T screen-256color every time, one can just put
> 'term screen-256color' into .screenrc.  I'll update the docs to show this
> when I make the release current.

Is there any reason that I shouldn't put this command into the default
/etc/screenrc file?  Are there terminal types for which it would cause problems?

I just tried this with a DOS terminal, which doesn't support 256 colors AFAIK. 
It didn't make any difference that I could tell.

Maybe I'll put out another test release with that change, and see if anyone
complains.

A.



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

std::arg() bug : not repetitive ?

[Marco Atzeri]

Hi DaveK,
the following test case on complex numbers 
is producing, puzzling result on cygwin (both 1.5 and 1,7) 
with gcc-4.3.2 (and also 3.4.4), while working on other platform:

#include 
#include "oct-cmplx.h"

int main ()
{
  Complex z1 (1.0, 1.0), z2 (1.0, 1.0);
  std::cout << (arg(z1)) << '\n';
  std::cout << (arg(z2)) << '\n';
  std::cout << (arg(z1)

oct-cmplx.h
Description: Binary data


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

Re: 1.7.0-60: diff -qr crashes

[Christopher Faylor]

On Tue, Sep 01, 2009 at 04:47:16PM +0200, Torsten Sch?tze wrote:
>Christopher Faylor wrote:
>Okay, here we are. Using the 2009-09-01 snapshot
>(cygwin1-20090901.dll.bz2, cygwin1-20090901.dbg.bz2) I obtain:
>
>First, in directory 2009 (corresponds to diff.exe.stackdump-1), see
>attachment diff.exe.stackdump-1-new
>
>Exception: STATUS_ACCESS_VIOLATION at eip=C128
>eax= ebx= ecx=0022B3BC edx=7C90E514 esi=
>edi=
>ebp=0022B3C8 esp=0022B3C8 program=C:\cygwin\bin\diff.exe, pid 260,
>thread main
>cs=001B ds=0023 es=0023 fs=003B gs= ss=0023
>Stack trace:
>Frame Function  Args
>0022B3C8  C128  (0724, EA60, 00A4, 0022B4BC)
>0022B4D8  610B9EA5  (6120BFEC, 0001, 003B0023, 0023)
>0022B598  610BA75A  (0001, 0022B654, 10062718, 610CA934)
>0022B5A8  610BA7EF  (, 0001, 0022B5F8, )
>10062718  610CA934  (6F632F41, 4F2F6564, 536E6570, 682F4143)
>End of stack trace

Hmm.  Not much help.  From looking at the code it looks like a corrupted
stack except the stack obviously isn't corrupted.

Is there any chance that you could send me the contents of the two
directories that you're diffing?  I understand if this is proprietary
stuff but I don't think I'm going to get much from a stackdump or
strace.

Assuming it's possible, please send a compressed .tar.bz2 file to

cgf
>at<
cygwin
>dot<
com

cgf

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

Re: [ANNOUNCEMENT] Updated: screen, now with 256-color support!

[Andrew Schulman]

Andy Koppe  gmail.com> writes:
> 
> Andrew Schulman:
> > Instructions for starting screen with 256 color support are in
> > /usr/share/doc/screen/README.Cygwin.  In brief, you have to invoke screen
> > as
> >
> > TERM=screen-256color screen
> 
> I don't think that's quite right. Screen needs to be told what
> terminal it is itself running in. This means "xterm-256color" for
> xterm, PuTTY and MinTTY, and "rxvt-256color" for rxvt.
> 
> Inside screen, however, the TERM variable does need to be set to
> "screen-256color" to tell termcap/terminfo-using programs that they
> are running in a 256-color-enabled screen. The -T option can be used
> for that. So, for example:
> 
> TERM=xterm-256color screen -T screen-256color

Andy, thanks.  Yes, you're right.  When I run screen as you suggest,
several color artifacts disappear.  In particular I get 16 system colors
instead of just 8.

Instead of specifying -T screen-256color every time, one can just put
'term screen-256color' into .screenrc.  I'll update the docs to show this
when I make the release current.

Andrew.



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

Re: 1.7.0-60: diff -qr crashes

[Torsten Schütze]

Christopher Faylor wrote:
> On Tue, Sep 01, 2009 at 04:01:06PM +0200, Torsten Sch?tze wrote:
>> Hi,
>>
>> I've installed Cygwin Beta 1.7.0 (version -51) around mid of July.
>> Currently, version -60 is installed. Now (at least since version -53 or
>> so) I repeatedly encounter a bug with diff (diffutils 2.8.7-1). I use
>> diff to compare my working directory with the files on an usb stick. The
>> exact command line is
>>
>> diff -qr . /cygdrive/w/user/schuetze/work/2009
>>
>> Note that the 32 GByte usb stick (cygdrive w) is encrypted with
>> truecrypt 6.2a and formatted as FAT32. (Don't know if this matters. But
>> the error occurs with other directories as well.)
>>
>> Depending on the exact place in the file system I'll get a core dump
>> immediately or first some errors and then the core dump.
>>
>> bash-3.2$ pwd
>> /cygdrive/e/user/schuetze/work/2009
>> bash-3.2$ diff -qr . /cygdrive/w/user/schuetze/work/2009
>>  1 [main] diff 2376 sig_send: error sending signal -34 to pid 2376,
>> pipe handle 0x750, Win32 error 998
>> Segmentation fault (core dumped)
> 
> I guess this is my excuse to roll a new version of Cygwin.  Since Corinna
> doesn't include the .dbg file in her releases, I can't decode the stack
> traces from the attached .stackdump files.
> 
> Or, hmm.  It guess it would be better if I released a snapshot before a
> new release.
> 
> Could you try to duplicate this with today's snapshot from:
> 
> http://cygwin.com/snapshots/
> 
> I'm generating it now.  Please wait for the September 1 snapshot to
> show up before trying anything.
Okay, here we are. Using the 2009-09-01 snapshot
(cygwin1-20090901.dll.bz2, cygwin1-20090901.dbg.bz2) I obtain:

First, in directory 2009 (corresponds to diff.exe.stackdump-1), see
attachment diff.exe.stackdump-1-new

Exception: STATUS_ACCESS_VIOLATION at eip=C128
eax= ebx= ecx=0022B3BC edx=7C90E514 esi=
edi=
ebp=0022B3C8 esp=0022B3C8 program=C:\cygwin\bin\diff.exe, pid 260,
thread main
cs=001B ds=0023 es=0023 fs=003B gs= ss=0023
Stack trace:
Frame Function  Args
0022B3C8  C128  (0724, EA60, 00A4, 0022B4BC)
0022B4D8  610B9EA5  (6120BFEC, 0001, 003B0023, 0023)
0022B598  610BA75A  (0001, 0022B654, 10062718, 610CA934)
0022B5A8  610BA7EF  (, 0001, 0022B5F8, )
10062718  610CA934  (6F632F41, 4F2F6564, 536E6570, 682F4143)
End of stack trace

In directory 2008 the list of warnings and errors is much longer now,
but it doesn't core dump now.

bash-3.2$ cd ../2008
bash-3.2$ diff -qr . /cygdrive/w/user/schuetze/work/2008
  1 [main] diff 3760 sig_send: error sending signal -34 to pid 3760,
pipe handle 0x750, Win32 error 998
11319792 [main] diff 3760 sig_send: error sending signal -34 to pid
3760, pipe handle 0x750, Win32 error 998
21282830 [main] diff 3760 sig_send: error sending signal -34 to pid
3760, pipe handle 0x750, Win32 error 998
23541033 [main] diff 3760 sig_send: error sending signal -34 to pid
3760, pipe handle 0x750, Win32 error 998
Only in .: diff.exe.stackdump-2
52864686 [main] diff 3760 sig_send: error sending signal -34 to pid
3760, pipe handle 0x750, Win32 error 998
52866298 [main] diff 3760 sig_send: error sending signal -34 to pid
3760, pipe handle 0x750, Win32 error 998
52869051 [main] diff 3760 sig_send: error sending signal -34 to pid
3760, pipe handle 0x750, Win32 error 998
52871923 [main] diff 3760 sig_send: error sending signal -34 to pid
3760, pipe handle 0x750, Win32 error 998
52874798 [main] diff 3760 sig_send: error sending signal -34 to pid
3760, pipe handle 0x750, Win32 error 998
52879422 [main] diff 3760 sig_send: error sending signal -34 to pid
3760, pipe handle 0x750, Win32 error 998
52882299 [main] diff 3760 sig_send: error sending signal -34 to pid
3760, pipe handle 0x750, Win32 error 998
53111327 [main] diff 3760 sig_send: error sending signal -34 to pid
3760, pipe handle 0x750, Win32 error 998
53143058 [main] diff 3760 sig_send: error sending signal -34 to pid
3760, pipe handle 0x750, Win32 error 998
53144671 [main] diff 3760 sig_send: error sending signal -34 to pid
3760, pipe handle 0x750, Win32 error 998
54526911 [main] diff 3760 sig_send: error sending signal -34 to pid
3760, pipe handle 0x750, Win32 error 998
54531401 [main] diff 3760 sig_send: error sending signal -34 to pid
3760, pipe handle 0x750, Win32 error 998
bash-3.2$

Hope this helps
  Torsten
Exception: STATUS_ACCESS_VIOLATION at eip=C128
eax= ebx= ecx=0022B3BC edx=7C90E514 esi= edi=
ebp=0022B3C8 esp=0022B3C8 program=C:\cygwin\bin\diff.exe, pid 260, thread main
cs=001B ds=0023 es=0023 fs=003B gs= ss=0023
Stack trace:
Frame Function  Args
0022B3C8  C128  (0724, EA60, 00A4, 0022B4BC)
0022B4D8  610B9EA5 

Re: 1.7.0-60: diff -qr crashes

[Christopher Faylor]

On Tue, Sep 01, 2009 at 04:01:06PM +0200, Torsten Sch?tze wrote:
>Hi,
>
>I've installed Cygwin Beta 1.7.0 (version -51) around mid of July.
>Currently, version -60 is installed. Now (at least since version -53 or
>so) I repeatedly encounter a bug with diff (diffutils 2.8.7-1). I use
>diff to compare my working directory with the files on an usb stick. The
>exact command line is
>
>diff -qr . /cygdrive/w/user/schuetze/work/2009
>
>Note that the 32 GByte usb stick (cygdrive w) is encrypted with
>truecrypt 6.2a and formatted as FAT32. (Don't know if this matters. But
>the error occurs with other directories as well.)
>
>Depending on the exact place in the file system I'll get a core dump
>immediately or first some errors and then the core dump.
>
>bash-3.2$ pwd
>/cygdrive/e/user/schuetze/work/2009
>bash-3.2$ diff -qr . /cygdrive/w/user/schuetze/work/2009
>  1 [main] diff 2376 sig_send: error sending signal -34 to pid 2376,
>pipe handle 0x750, Win32 error 998
>Segmentation fault (core dumped)

I guess this is my excuse to roll a new version of Cygwin.  Since Corinna
doesn't include the .dbg file in her releases, I can't decode the stack
traces from the attached .stackdump files.

Or, hmm.  It guess it would be better if I released a snapshot before a
new release.

Could you try to duplicate this with today's snapshot from:

http://cygwin.com/snapshots/

I'm generating it now.  Please wait for the September 1 snapshot to
show up before trying anything.

cgf

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

Re: GNU screen hangs

[Christopher Faylor]

On Tue, Sep 01, 2009 at 07:12:51AM -0700, Andrew DeFaria wrote:
>TV wrote:
>>Oh, this is must be a cultural thing about americans and their tanned
>>tongues.
>Excuse me, I'm off to the tongue tanning salon...  ;-)

Ok.  I've got to stop drinking coffee while reading the cygwin list...

cgf

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

Re: GNU screen hangs

[Andrew DeFaria]

TV wrote:
Oh, this is must be a cultural thing about americans and their tanned 
tongues.

Excuse me, I'm off to the tongue tanning salon... ;-)
--
Andrew DeFaria 
The gene pool sure could use a little chlorine.


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

1.7.0-60: diff -qr crashes

[Torsten Schütze]

Hi,

I've installed Cygwin Beta 1.7.0 (version -51) around mid of July.
Currently, version -60 is installed. Now (at least since version -53 or
so) I repeatedly encounter a bug with diff (diffutils 2.8.7-1). I use
diff to compare my working directory with the files on an usb stick. The
exact command line is

diff -qr . /cygdrive/w/user/schuetze/work/2009

Note that the 32 GByte usb stick (cygdrive w) is encrypted with
truecrypt 6.2a and formatted as FAT32. (Don't know if this matters. But
the error occurs with other directories as well.)

Depending on the exact place in the file system I'll get a core dump
immediately or first some errors and then the core dump.

bash-3.2$ pwd
/cygdrive/e/user/schuetze/work/2009
bash-3.2$ diff -qr . /cygdrive/w/user/schuetze/work/2009
  1 [main] diff 2376 sig_send: error sending signal -34 to pid 2376,
pipe handle 0x750, Win32 error 998
Segmentation fault (core dumped)

One folder downwards the file hierarchy everything works fine, at least
today. But with

bash-3.2$ pwd
/cygdrive/e/user/schuetze/work/2008
bash-3.2$ diff -qr . /cygdrive/w/user/schuetze/work/2008
  1 [main] diff 3692 _cygtls::handle_exceptions: Error while dumping
state (probably corrupted stack)
Segmentation fault (core dumped)

I will attach both diff.exe.stackdump, the core file from the folder
2009 as diff.exe.stackdump-1, the one from the 2008 folder as
diff.exe.stackdump-2.

Note, that there are no errors with Cygwin 1.5 (cygwin 1.5.24).

My questions are:
- Is this a known error with Cygwin 1.7.0-60?
- What can I do about it? Is there a fix available?
- Is the stack dump helpful or should I compile diff with debug symbols
and gdb diff?

If required I can provide the output of cygcheck -s -v -r

Torsten
Exception: STATUS_ACCESS_VIOLATION at eip=C128
eax= ebx= ecx=0022B3BC edx=7C90E514 esi= edi=
ebp=0022B3C8 esp=0022B3C8 program=C:\cygwin\bin\diff.exe, pid 2376, thread main
cs=001B ds=0023 es=0023 fs=003B gs= ss=0023
Stack trace:
Frame Function  Args
0022B3C8  C128  (0728, EA60, 00A4, 0022B4BC)
0022B4D8  610B9C85  (6120C50C, 0001, 003B0023, 0023)
0022B598  610BA53A  (0001, 0022B654, 10062738, 610CA724)
0022B5A8  610BA5CF  (, 0001, 0022B5F8, )
10062738  610CA724  (6F632F41, 4F2F6564, 536E6570, 682F4143)
End of stack trace
Exception: STATUS_ACCESS_VIOLATION at eip=C128
eax= ebx= ecx=0022BEFC edx=7C90E514 esi= edi=
ebp=0022BF08 esp=0022BF08 program=C:\cygwin\bin\diff.exe, pid 3692, thread main
cs=001B ds=0023 es=0023 fs=003B gs= ss=0023
Stack trace:
Frame Function  Args
0022BF08  C128  (072C, EA60, 00A4, 0022BFFC)
0022C018  610B9C85  (6120910C, 0001, , )
0022C0D8  610BA53A  (6120C81C, , 10061250, 610CA724)
0022C0E8  610BA5CF  (, , 0022C158, 6100229F)
10061250  610CA724  (7463656C, 73657275, 6369702F, 65727574)
  1 [main] diff 3692 _cygtls::handle_exceptions: Error while dumping state 
(probably corrupted stack)
--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: BitDefender again

[Michael Kairys]

Or you can go the easy route, and follow the instructions they have 
provided to rebase cygwin.dll.


I shall try their instructions and report back. (There must be other 
BitDefender users similarily inconvenienced by version 2010 :) 




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

Re: [OT] Re: GNU screen hangs

[Dave Korn]

One more time wrote:
> Ah, censorship. 

  zOMG we is suppressing your freedumb of speach!  O noes!  Call for the
WH-bulance!

  Seriously, that is the kind of pathetic nonsense spammers come out with.

> You clearly read the messages through some anti-tuomov glasses,
> as most of the FOSS herd does. It's not like I'm liked much for 
> pointing out where it's all heading, and my anti-distro licensing. 
> So the herd attacks the message thanks to the messenger.

  Oh, so you are a noble fighter for freedom, a voice crying out in the
wilderness, and anyone who thinks you're a jerk is just a gullible fool with
no independent thought, following the herd.

  Ha ha, no.  Sure, they laughed at Galileo, they laughed at Copernicus, they
laughed at Columbus and Newton and Einstein.

  But they also laughed at Bozo the Clown.

  You're not trying to help anyone out or point the way.  You posted a
RRAGEE-filled angry self-pitying rant.  And then you expect to be treated
as some kind of hero.  Like I said, narcissistic vanity.  It makes you an
unpleasant person to be around.

  Face the facts: I have never met or heard of you before; it's entirely down
to the unpleasant tone of your first post and your subsequent descent into
full-on trollhood.  I am not following any herd, I made my own mind up, and
long before you started being deliberately rude for no reason over the issue
of quoting people's email addresses; it's precisely because I have an
independent mind that I think you're a jerk.

  I've set the Followup-to header to the suitable list for continuing this
off-topic discussion.

DaveK

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

Re: [OT] Re: GNU screen hangs

[One more time]

Ah, censorship. The Official Truth will become the Truth,
when the opposition is censored.

On 2009-09-01, Dave Korn  wrote:
>   Nonsense, it's got nothing to do with the way you say it, it's the content
> of your message that nobody likes: self-regarding vanity, arrogance and
> me-first egotism.  Unwarranted self-importance, much?

You clearly read the messages through some anti-tuomov glasses,
as most of the FOSS herd does. It's not like I'm liked much for 
pointing out where it's all heading, and my anti-distro licensing. 
So the herd attacks the message thanks to the messenger.

>   Spammers don't subscribe to mailing lists to harvest addresses. They scrape
> them off the web archives.  The headers are munged in the archives.  The
> bodies are not.  You're just trying to justify lazy selfishness.

Any sane archive will obfuscate both content and headers, if it all.
This list is archived at http://news.gmane.org/gmane.os.cygwin/, and
available by NNTP through news.gmage.org, both of which spammers can
use. The former poorly obfuscates both (with @ replaced by ), 
the latter doesn't. Gmane can be configured to fully obsfuscate
addresses, but nobody has done it for this list. And yet people
carelessly post their real addresses in the headers... as if it's
worth the effort of trying to keep addresses out of spammers' hands. 
Better stay of the 'net.

No, the real reason for complaining about quoting an address has
nothing to do with spam. You just wanted some excuse for attacking 
me with some nitpicky rules...  on a list that is listed as the 
only place for users to report bugs, trying to help both the
project and themselves. But, no, the attitude among FOSS developers
these days is tha their project has no bugs, and they don't want
to hear about it, so it's made extremely difficult to report 
them... registering on some suckzilla, subscribing on a mailing
list (because apparently accessing through NNTP isn't really
allowed, even when available), listening to power-blind assholes
complain about some ridiculous directives hidden in some tome 
of Sacred Etiquette.

Signing off. Pitäkää tunkkinne!

-- 
Tuomo




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

[OT] Re: GNU screen hangs

[Dave Korn]

TV wrote:
> On 2009-09-01, Dave Korn wrote:

  Wow.  You kind of quoted my email address, but then you went and changed it
into some poor innocent bystander's account.  Whoever that is won't be pleased
with you.

  <  this space left blank for Tuomo to explain why that's the innocent
bystander's fault, and not his for using a buggy newsreader  >

>>   Don't kid yourself: it's you that's at fault, not the whole rest of the
>> world.  You've been rude and arrogant from your first post.  
> 
> Oh, this is must be a cultural thing about americans and
> their tanned tongues. 

  I'm not even a little bit American, you silly little bigot.

> Can't stay to the facts, have to 
> make everything dripping with sugar, otherwise it's 
> considered rude. 

  Nonsense, it's got nothing to do with the way you say it, it's the content
of your message that nobody likes: self-regarding vanity, arrogance and
me-first egotism.  Unwarranted self-importance, much?

>>   Posting people's email addresses gets them spammed.  
> 
> And the addresses are right there in the From-fields.

  Spammers don't subscribe to mailing lists to harvest addresses.  They scrape
them off the web archives.  The headers are munged in the archives.  The
bodies are not.  You're just trying to justify lazy selfishness.

DaveK

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

Re: GNU screen hangs

[Christopher Faylor]

On Tue, Sep 01, 2009 at 10:23:58AM +, TV wrote:
>On 2009-09-01, Dave Korn  wrote:
>>Don't kid yourself: it's you that's at fault, not the whole rest of the
>>world.  You've been rude and arrogant from your first post.
>
>Oh, this is must be a cultural thing about americans and their tanned
>tongues.  Can't stay to the facts, have to make everything dripping
>with sugar, otherwise it's considered rude.

Heh.  DaveK is an American now.  When did that happen?

cgf

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

Re: GNU screen hangs

[TV]

On 2009-09-01, Dave Korn  wrote:
>   Don't kid yourself: it's you that's at fault, not the whole rest of the
> world.  You've been rude and arrogant from your first post.  

Oh, this is must be a cultural thing about americans and
their tanned tongues. Can't stay to the facts, have to 
make everything dripping with sugar, otherwise it's 
considered rude. 

>   Posting people's email addresses gets them spammed.  

And the addresses are right there in the From-fields.

-- 
Be an early adopter! Beat the herd! Choose Windows today!


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

Re: GNU screen hangs

[Dave Korn]

TV wrote:
> On 2009-08-31, Christopher Faylor
 wrote:
>> Apparently you don't know who I am.
>
> An even bigger pile of

  Don't kid yourself: it's you that's at fault, not the whole rest of the
world.  You've been rude and arrogant from your first post.  It's certainly
not just him who thinks so, I was going to reply about three separate times
until I saw what you were doing.

  Posting people's email addresses gets them spammed.  It's not just a petty
rule, it's a verified fact proven by scientific experimentation and
measurement.  Here's proof:
 http://www.cdt.org/speech/spam/030319spamreport.shtml

 Deliberately violating list netiquette and morphing your From: line to evade
a ban is regarded as network abuse pretty much everywhere.  It's certainly
anti-social.

DaveK


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

Re: GNU screen hangs

[TV]

On 2009-08-31, Christopher Faylor  
wrote:
> Apparently you don't know who I am.

An even bigger pile of shit than this project. A project leader
pretending to be an army sergeant with users rookies required
to follow his ridiculous commands.

I guess I'm going to complete my transition from Linux to
Windows, and ditch Cygwin too. It has no hope with such
piles of shit at the top.


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