public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
From: "E. Robert Tisdale" <edwin@netwood.net>
To: cygwin@sourceware.cygnus.com
Subject: Re: setmode (long)
Date: Thu, 25 Feb 1999 12:12:00 -0000	[thread overview]
Message-ID: <36D5ADF0.C5FC769@netwood.net> (raw)
In-Reply-To: <3.0.5.32.19990225144311.0084fc50@pop.ne.mediaone.net>

Pierre A. Humblet wrote:

> I had a second look (b20.1 on win95) at your problem
> and it's not what I thought initially,
> i.e. a basic problem with the cygwin layer in b20.1,
> which tends to open too many files as binary.
>
> In your output, each time you look at test.out
> the FIRST return of setmode is the same as the argument of setmode,
> i.e. O_TEXT. Thus in all your runs the file was initially TEXT,
> although the output appears to be binary.
> At any rate setmode had no effect.
>
> Next I duplicated your experiments (standard g++ in b20.1 only).
> I don't trust editors to look at CR in files and used "od -c test.out".
> That shows an extra  ^M on all lines compared to your output.
> On a binary mounted system test.out is initially binary (as it should),
> but the output is the same.  Also setmode works for stdout.
>
> Next I wrote a similar test in C. There setmode works as expected.
>
> I am wondering what you see if you look at your files with od -c,
> and if you agree that setmode works in a C program
> (that would point to a C++ error (?))

I verified the results of `vi' (`vim' not `elvis')
with the results of `od' before I sent the original message.
I included the results from `vi' in my original message
because they are easier to read.
I thought it would be obvious from the `test.dos' and `test.cyg' output
that `vi' accurately represented the actual contents of the file.

Do `vi' and `od' give you different results on your system?

E. Robert Tisdale <edwin@netwood.net>


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

WARNING: multiple messages have this Message-ID
From: "E. Robert Tisdale" <edwin@netwood.net>
To: cygwin@sourceware.cygnus.com
Subject: Re: setmode (long)
Date: Sun, 28 Feb 1999 23:02:00 -0000	[thread overview]
Message-ID: <36D5ADF0.C5FC769@netwood.net> (raw)
Message-ID: <19990228230200.DVk1r5-7UVSEmPP6_yu4xzkFF_y064-JvbXuMW7bnUw@z> (raw)
In-Reply-To: <3.0.5.32.19990225144311.0084fc50@pop.ne.mediaone.net>

Pierre A. Humblet wrote:

> I had a second look (b20.1 on win95) at your problem
> and it's not what I thought initially,
> i.e. a basic problem with the cygwin layer in b20.1,
> which tends to open too many files as binary.
>
> In your output, each time you look at test.out
> the FIRST return of setmode is the same as the argument of setmode,
> i.e. O_TEXT. Thus in all your runs the file was initially TEXT,
> although the output appears to be binary.
> At any rate setmode had no effect.
>
> Next I duplicated your experiments (standard g++ in b20.1 only).
> I don't trust editors to look at CR in files and used "od -c test.out".
> That shows an extra  ^M on all lines compared to your output.
> On a binary mounted system test.out is initially binary (as it should),
> but the output is the same.  Also setmode works for stdout.
>
> Next I wrote a similar test in C. There setmode works as expected.
>
> I am wondering what you see if you look at your files with od -c,
> and if you agree that setmode works in a C program
> (that would point to a C++ error (?))

I verified the results of `vi' (`vim' not `elvis')
with the results of `od' before I sent the original message.
I included the results from `vi' in my original message
because they are easier to read.
I thought it would be obvious from the `test.dos' and `test.cyg' output
that `vi' accurately represented the actual contents of the file.

Do `vi' and `od' give you different results on your system?

E. Robert Tisdale <edwin@netwood.net>


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com


       reply	other threads:[~1999-02-25 12:12 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <3.0.5.32.19990225144311.0084fc50@pop.ne.mediaone.net>
1999-02-25 12:12 ` E. Robert Tisdale [this message]
     [not found]   ` < 36D5ADF0.C5FC769@netwood.net >
1999-02-25 18:48     ` Pierre A. Humblet
     [not found]       ` < 3.0.5.32.19990225215015.00857270@pop.ne.mediaone.net >
1999-02-25 18:57         ` Mumit Khan
1999-02-25 22:29           ` E. Robert Tisdale
1999-02-28 23:02             ` E. Robert Tisdale
1999-02-28 23:02           ` Mumit Khan
1999-02-28 23:02       ` Pierre A. Humblet
1999-02-28 23:02   ` E. Robert Tisdale
     [not found] ` <3.0.5.32.19990225152844.008374c0@pop.ne.mediaone.net>
1999-02-25 21:56   ` E. Robert Tisdale
1999-02-28 23:02     ` E. Robert Tisdale
1999-02-26  2:47 Bernard Dautrevaux
1999-02-28 23:02 ` Bernard Dautrevaux
1999-03-03 19:19 ` E. Robert Tisdale
1999-03-31 19:45   ` E. Robert Tisdale
  -- strict thread matches above, loose matches on Subject: below --
1999-02-24  0:31 E. Robert Tisdale
     [not found] ` < 36D39A03.89B3C703@netwood.net >
1999-02-24 11:42   ` Christopher Faylor
1999-02-25  1:26     ` E. Robert Tisdale
     [not found]       ` < 36D51691.6E1579DF@netwood.net >
1999-02-25  8:02         ` DJ Delorie
1999-02-25 22:44           ` E. Robert Tisdale
1999-02-28 23:02             ` E. Robert Tisdale
1999-02-28 23:02           ` DJ Delorie
1999-02-25  9:25         ` Mumit Khan
1999-02-28 23:02           ` Mumit Khan
1999-02-28 23:02       ` E. Robert Tisdale
1999-03-02 18:59       ` Christopher Faylor
1999-03-03 19:29         ` E. Robert Tisdale
     [not found]           ` < 36DDFD4C.B4B6F7C4@netwood.net >
1999-03-04  8:17             ` Chris Faylor
1999-03-31 19:45               ` Chris Faylor
1999-03-31 19:45           ` E. Robert Tisdale
1999-03-31 19:45         ` Christopher Faylor
1999-02-28 23:02     ` Christopher Faylor
1999-02-28 23:02 ` E. Robert Tisdale

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=36D5ADF0.C5FC769@netwood.net \
    --to=edwin@netwood.net \
    --cc=cygwin@sourceware.cygnus.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).