Not with Win32! Have a look into src/support/os_win32.C. There
os::read:mode() does return rb for Win32!
I think this has nothing to do with the \r in LaTeX.C. There an ordinary
ifstream is used without giving the std::ios_base::binary flag, so this
should read in text mode.
What the *
On Wed, Jan 08, 2003 at 09:55:18AM +0100, Claus Hentschel wrote:
Lyx should run independent from the mode a drive is mounted. Therefore we
need binary mode in some cases and text mode in some other cases whereas in
most cases it doesn't matter.
Of course it could be done easier with
Andre Poenitz [EMAIL PROTECTED] writes:
| On Wed, Jan 08, 2003 at 09:55:18AM +0100, Claus Hentschel wrote:
| Lyx should run independent from the mode a drive is mounted. Therefore we
| need binary mode in some cases and text mode in some other cases whereas in
| most cases it doesn't matter.
|
| Of course it could be done easier with
| ifstream ifs(tmp.c_str(), ios::in | ios::text);
| Maybe we should include that instead ;-) And we can rewrite all calls
to
| open a file for both reading and writing.
|
| Does that work?
No, not with gcc, because gcc is conform with ANSI.
Claus Hentschel [EMAIL PROTECTED] writes:
| | Of course it could be done easier with
| | ifstream ifs(tmp.c_str(), ios::in | ios::text);
| | Maybe we should include that instead ;-) And we can rewrite all calls
| to
| | open a file for both reading and writing.
| |
| | Does that
| ios::text? No. It is a non-standard flag.
| ...
| ios::binary otoh is a standard flag and should work everywhere.
|
| So there seems not to be another way then removong those trailing \r's
the
| way I'v done. We do need that in all cases where text read from a
(binary)
| opened file is
Claus Hentschel [EMAIL PROTECTED] writes:
| | ios::text? No. It is a non-standard flag.
| | ...
| | ios::binary otoh is a standard flag and should work everywhere.
| |
| | So there seems not to be another way then removong those trailing \r's
| the
| | way I'v done. We do need that in
> > Not with Win32! Have a look into src/support/os_win32.C. There
> > os::read:mode() does return "rb" for Win32!
>
> I think this has nothing to do with the \r in LaTeX.C. There an ordinary
> ifstream is used without giving the std::ios_base::binary flag, so this
> should read in text mode.
>
>
On Wed, Jan 08, 2003 at 09:55:18AM +0100, Claus Hentschel wrote:
> Lyx should run independent from the mode a drive is mounted. Therefore we
> need binary mode in some cases and text mode in some other cases whereas in
> most cases it doesn't matter.
>
> Of course it could be done easier with
>
Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Wed, Jan 08, 2003 at 09:55:18AM +0100, Claus Hentschel wrote:
| > Lyx should run independent from the mode a drive is mounted. Therefore we
| > need binary mode in some cases and text mode in some other cases whereas in
| > most cases it doesn't
> | > Of course it could be done easier with
> | > ifstream ifs(tmp.c_str(), ios::in | ios::text);
> | > Maybe we should include that instead ;-) And we can rewrite all calls
to
> | > open a file for both reading and writing.
> |
> | Does that work?
No, not with gcc, because gcc is conform
"Claus Hentschel" <[EMAIL PROTECTED]> writes:
| > | > Of course it could be done easier with
| > | > ifstream ifs(tmp.c_str(), ios::in | ios::text);
| > | > Maybe we should include that instead ;-) And we can rewrite all calls
| to
| > | > open a file for both reading and writing.
| > |
| > |
> | > ios::text? No. It is a non-standard flag.
> | > ...
> | > ios::binary otoh is a standard flag and should work everywhere.
> |
> | So there seems not to be another way then removong those trailing \r's
the
> | way I'v done. We do need that in all cases where text read from a
(binary)
> |
"Claus Hentschel" <[EMAIL PROTECTED]> writes:
| > | > ios::text? No. It is a non-standard flag.
| > | > ...
| > | > ios::binary otoh is a standard flag and should work everywhere.
| > |
| > | So there seems not to be another way then removong those trailing \r's
| the
| > | way I'v done. We do
Andre Poenitz [EMAIL PROTECTED] writes:
| On Mon, Jan 06, 2003 at 09:41:01PM +0100, Lars Gullik Bjønnes wrote:
| | A single char obviously can't be '\r\n'. So I'd indeed expect a '\r' at the
| | end of the string read by getline(...'\n') -- unless this has something
| | to do with that 'binary
Andre == Andre Poenitz [EMAIL PROTECTED] writes:
Andre The problem is, not to many people here have a Windows
Andre development system to check. The ifstream in question is not
Andre opened in binary mode as far as I can tell, so optically it
Andre should work. Nevertheless, the '\r' show up for
On Tue, Jan 07, 2003 at 10:37:19AM +0100, Lars Gullik Bjønnes wrote:
all calls to getline is followed by a call to rtrim...
Indeed.
I now just wonder why the removal of the '\r' is necessary at all.
It shouldn't for the common case of putting the line into istringstream and
reading from there.
On Tue, Jan 07, 2003 at 10:44:52AM +0100, Jean-Marc Lasgouttes wrote:
Andre The problem is, not to many people here have a Windows
Andre development system to check. The ifstream in question is not
Andre opened in binary mode as far as I can tell, so optically it
Andre should work.
Andre Poenitz [EMAIL PROTECTED] writes:
| I wonder what happens if we used
|
| getline(s,n,widen('\n'))
This is just what getline(s, n) ends up in.
--
Lgb
Andre Poenitz [EMAIL PROTECTED] writes:
| On Tue, Jan 07, 2003 at 10:37:19AM +0100, Lars Gullik Bjønnes wrote:
| all calls to getline is followed by a call to rtrim...
|
| Indeed.
|
| I now just wonder why the removal of the '\r' is necessary at all.
|
| It shouldn't for the common case of
Lars == Lars Gullik Bjønnes [EMAIL PROTECTED] writes:
Lars Andre Poenitz [EMAIL PROTECTED] writes:
Lars | On Mon, Jan 06, 2003 at 09:41:01PM +0100, Lars Gullik Bjønnes wrote:
Lars | | A single char obviously can't be '\r\n'. So I'd indeed
Lars expect a '\r' at the | | end of the string read by
I just got confirmation from de.comp.lang.iso-c++ that
getline() should never return the '\r' if the stream is in
text mode.
So which compiler was that?
The only possibility is a '\r\r\n' in the raw input...
Andre'
--
Those who desire to give up Freedom in order to gain Security,
will
Andre == Andre Poenitz [EMAIL PROTECTED] writes:
Andre On Tue, Jan 07, 2003 at 10:37:19AM +0100, Lars Gullik Bjønnes
Andre wrote:
all calls to getline is followed by a call to rtrim...
Andre Indeed.
Andre I now just wonder why the removal of the '\r' is necessary at
Andre all.
Andre It
On Tue, Jan 07, 2003 at 12:43:14PM +0100, Jean-Marc Lasgouttes wrote:
Andre It shouldn't for the common case of putting the line into
Andre istringstream and reading from there.
Why? What is the magic making this happen?
The streambuffer layer. I have asked what this means ;-)
Andre'
--
On Tue, Jan 07, 2003 at 12:31:00PM +0100, Andre' Poenitz wrote:
I just got confirmation from de.comp.lang.iso-c++ that
getline() should never return the '\r' if the stream is in
text mode.
Next asnwer says: This is a well-known bug in some Borland Compiler
(BCB5). Upgrading or using gcc
Andre Poenitz [EMAIL PROTECTED] writes:
| On Tue, Jan 07, 2003 at 12:31:00PM +0100, Andre' Poenitz wrote:
| I just got confirmation from de.comp.lang.iso-c++ that
| getline() should never return the '\r' if the stream is in
| text mode.
|
| Next asnwer says: This is a well-known bug in
Lars == Lars Gullik Bjønnes [EMAIL PROTECTED] writes:
Lars Andre Poenitz [EMAIL PROTECTED] writes:
Lars | On Tue, Jan 07, 2003 at 12:31:00PM +0100, Andre' Poenitz wrote:
Lars | I just got confirmation from de.comp.lang.iso-c++ that |
Lars getline() should never return the '\r' if the stream is
Lars Andre Poenitz [EMAIL PROTECTED] writes:
Lars | On Tue, Jan 07, 2003 at 12:31:00PM +0100, Andre' Poenitz wrote:
Lars | I just got confirmation from de.comp.lang.iso-c++ that |
Lars getline() should never return the '\r' if the stream is in |
Lars text mode.
That's the reason! In Lyx
On Tue, Jan 07, 2003 at 05:27:33PM +0100, Claus Hentschel wrote:
Lars Andre Poenitz [EMAIL PROTECTED] writes:
Lars | On Tue, Jan 07, 2003 at 12:31:00PM +0100, Andre' Poenitz wrote:
Lars | I just got confirmation from de.comp.lang.iso-c++ that |
Lars getline() should never return the '\r'
Claus Hentschel [EMAIL PROTECTED] writes:
| Lars Andre Poenitz [EMAIL PROTECTED] writes:
| Lars | On Tue, Jan 07, 2003 at 12:31:00PM +0100, Andre' Poenitz wrote:
| Lars | I just got confirmation from de.comp.lang.iso-c++ that |
| Lars getline() should never return the '\r' if the stream is
On Tue, Jan 07, 2003 at 05:42:53PM +0100, Lars Gullik Bjønnes wrote:
| That's the reason! In Lyx we do open *all* files the same way, i.e. in
| binary mode by default.
On a win box text mode is default...
To be precise: text mode is everywhere default. But there is no difference
between text
Andre Poenitz [EMAIL PROTECTED] writes:
| On Tue, Jan 07, 2003 at 05:42:53PM +0100, Lars Gullik Bjønnes wrote:
| That's the reason! In Lyx we do open *all* files the same way, i.e. in
| binary mode by default.
On a win box text mode is default...
| To be precise: text mode is everywhere
That's the reason! In Lyx we do open *all* files the same way, i.e. in
binary mode by default.
No, the default mode is text.
Not with Win32! Have a look into src/support/os_win32.C. There
os::read:mode() does return rb for Win32!
To distinguish between text/binary mode we should have to
On Tue, Jan 07, 2003 at 06:13:36PM +0100, Claus Hentschel wrote:
That's the reason! In Lyx we do open *all* files the same way, i.e. in
binary mode by default.
No, the default mode is text.
Not with Win32! Have a look into src/support/os_win32.C. There
os::read:mode() does return rb
Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Mon, Jan 06, 2003 at 09:41:01PM +0100, Lars Gullik Bjønnes wrote:
| > | A single char obviously can't be '\r\n'. So I'd indeed expect a '\r' at the
| > | end of the string read by getline(...'\n') -- unless this has something
| > | to do with that
> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes:
Andre> The problem is, not to many people here have a Windows
Andre> development system to check. The ifstream in question is not
Andre> opened in binary mode as far as I can tell, so optically it
Andre> should work. Nevertheless, the
On Tue, Jan 07, 2003 at 10:37:19AM +0100, Lars Gullik Bjønnes wrote:
> all calls to getline is followed by a call to rtrim...
Indeed.
I now just wonder why the removal of the '\r' is necessary at all.
It shouldn't for the common case of putting the line into istringstream and
reading from
On Tue, Jan 07, 2003 at 10:44:52AM +0100, Jean-Marc Lasgouttes wrote:
> Andre> The problem is, not to many people here have a Windows
> Andre> development system to check. The ifstream in question is not
> Andre> opened in binary mode as far as I can tell, so optically it
> Andre> should work.
Andre Poenitz <[EMAIL PROTECTED]> writes:
| I wonder what happens if we used
|
| getline(s,n,widen('\n'))
This is just what getline(s, n) ends up in.
--
Lgb
Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Tue, Jan 07, 2003 at 10:37:19AM +0100, Lars Gullik Bjønnes wrote:
| > all calls to getline is followed by a call to rtrim...
|
| Indeed.
|
| I now just wonder why the removal of the '\r' is necessary at all.
|
| It shouldn't for the common case of
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> Andre Poenitz <[EMAIL PROTECTED]> writes:
Lars> | On Mon, Jan 06, 2003 at 09:41:01PM +0100, Lars Gullik Bjønnes wrote:
Lars> | > | A single char obviously can't be '\r\n'. So I'd indeed
Lars> expect a '\r' at the | > | end of
I just got confirmation from de.comp.lang.iso-c++ that
getline() should never return the '\r' if the stream is in
text mode.
So which compiler was that?
The only possibility is a '\r\r\n' in the raw input...
Andre'
--
Those who desire to give up Freedom in order to gain Security,
will
> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes:
Andre> On Tue, Jan 07, 2003 at 10:37:19AM +0100, Lars Gullik Bjønnes
Andre> wrote:
>> all calls to getline is followed by a call to rtrim...
Andre> Indeed.
Andre> I now just wonder why the removal of the '\r' is necessary at
Andre> all.
On Tue, Jan 07, 2003 at 12:43:14PM +0100, Jean-Marc Lasgouttes wrote:
> Andre> It shouldn't for the common case of putting the line into
> Andre> istringstream and reading from there.
>
> Why? What is the magic making this happen?
"The streambuffer layer". I have asked what this means ;-)
On Tue, Jan 07, 2003 at 12:31:00PM +0100, Andre' Poenitz wrote:
> I just got confirmation from de.comp.lang.iso-c++ that
> getline() should never return the '\r' if the stream is in
> text mode.
Next asnwer says: This is a well-known bug in some Borland Compiler
("BCB5"). Upgrading or using
Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Tue, Jan 07, 2003 at 12:31:00PM +0100, Andre' Poenitz wrote:
| > I just got confirmation from de.comp.lang.iso-c++ that
| > getline() should never return the '\r' if the stream is in
| > text mode.
|
| Next asnwer says: This is a well-known
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> Andre Poenitz <[EMAIL PROTECTED]> writes:
Lars> | On Tue, Jan 07, 2003 at 12:31:00PM +0100, Andre' Poenitz wrote:
Lars> | > I just got confirmation from de.comp.lang.iso-c++ that | >
Lars> getline() should never return the '\r'
> Lars> Andre Poenitz <[EMAIL PROTECTED]> writes:
> Lars> | On Tue, Jan 07, 2003 at 12:31:00PM +0100, Andre' Poenitz wrote:
> Lars> | > I just got confirmation from de.comp.lang.iso-c++ that | >
> Lars> getline() should never return the '\r' if the stream is in | >
> Lars> text mode.
That's the
On Tue, Jan 07, 2003 at 05:27:33PM +0100, Claus Hentschel wrote:
> > Lars> Andre Poenitz <[EMAIL PROTECTED]> writes:
> > Lars> | On Tue, Jan 07, 2003 at 12:31:00PM +0100, Andre' Poenitz wrote:
> > Lars> | > I just got confirmation from de.comp.lang.iso-c++ that | >
> > Lars> getline() should never
"Claus Hentschel" <[EMAIL PROTECTED]> writes:
| > Lars> Andre Poenitz <[EMAIL PROTECTED]> writes:
| > Lars> | On Tue, Jan 07, 2003 at 12:31:00PM +0100, Andre' Poenitz wrote:
| > Lars> | > I just got confirmation from de.comp.lang.iso-c++ that | >
| > Lars> getline() should never return the '\r'
On Tue, Jan 07, 2003 at 05:42:53PM +0100, Lars Gullik Bjønnes wrote:
> | That's the reason! In Lyx we do open *all* files the same way, i.e. in
> | binary mode by default.
>
> On a win box text mode is default...
To be precise: text mode is everywhere default. But there is no difference
between
Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Tue, Jan 07, 2003 at 05:42:53PM +0100, Lars Gullik Bjønnes wrote:
>> | That's the reason! In Lyx we do open *all* files the same way, i.e. in
>> | binary mode by default.
>>
>> On a win box text mode is default...
>
| To be precise: text mode is
> > That's the reason! In Lyx we do open *all* files the same way, i.e. in
> > binary mode by default.
>
> No, the default mode is text.
Not with Win32! Have a look into src/support/os_win32.C. There
os::read:mode() does return "rb" for Win32!
> > To distinguish between text/binary mode we
On Tue, Jan 07, 2003 at 06:13:36PM +0100, Claus Hentschel wrote:
> > > That's the reason! In Lyx we do open *all* files the same way, i.e. in
> > > binary mode by default.
> >
> > No, the default mode is text.
>
> Not with Win32! Have a look into src/support/os_win32.C. There
> os::read:mode()
Jean-Marc == Jean-Marc Lasgouttes [EMAIL PROTECTED] writes:
Jean-Marc The following patch is adapted from one of the last bits in
Jean-Marc the patch that Claus Hentschel uses on win32. It fixes
Jean-Marc parsing of log files by removing trailing \r.
Jean-Marc OK to apply?
Lars, can I apply
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes:
| The following patch is adapted from one of the last bits in the patch
| that Claus Hentschel uses on win32. It fixes parsing of log files by
| removing trailing \r.
|
| OK to apply?
Not sure...
I am not sure why this patch is needed. I thought
Lars == Lars Gullik Bjønnes [EMAIL PROTECTED] writes:
Lars Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: |
Lars The following patch is adapted from one of the last bits in the
Lars patch | that Claus Hentschel uses on win32. It fixes parsing of
Lars log files by | removing trailing \r.
Lars |
On Mon, Jan 06, 2003 at 06:43:28PM +0100, Lars Gullik Bjønnes wrote:
I am not sure why this patch is needed. I thought that a standard
conforming ifstream + getline would remove the line ending on the
system it runs. Thus in the case of win32 it should remove \r\n.
Hm.
templateclass charT,
Andre Poenitz [EMAIL PROTECTED] writes:
| A single char obviously can't be '\r\n'. So I'd indeed expect a '\r' at the
| end of the string read by getline(...'\n') -- unless this has something
| to do with that 'binary mode' vs 'text mode' and the \r is removed earlier.
| Somehow...
This is
On Mon, Jan 06, 2003 at 09:41:01PM +0100, Lars Gullik Bjønnes wrote:
| A single char obviously can't be '\r\n'. So I'd indeed expect a '\r' at the
| end of the string read by getline(...'\n') -- unless this has something
| to do with that 'binary mode' vs 'text mode' and the \r is removed
> "Jean-Marc" == Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
Jean-Marc> The following patch is adapted from one of the last bits in
Jean-Marc> the patch that Claus Hentschel uses on win32. It fixes
Jean-Marc> parsing of log files by removing trailing \r.
Jean-Marc> OK to apply?
Lars,
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| The following patch is adapted from one of the last bits in the patch
| that Claus Hentschel uses on win32. It fixes parsing of log files by
| removing trailing \r.
|
| OK to apply?
Not sure...
I am not sure why this patch is needed. I
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: |
Lars> The following patch is adapted from one of the last bits in the
Lars> patch | that Claus Hentschel uses on win32. It fixes parsing of
Lars> log files by | removing
On Mon, Jan 06, 2003 at 06:43:28PM +0100, Lars Gullik Bjønnes wrote:
> I am not sure why this patch is needed. I thought that a standard
> conforming ifstream + getline would remove the line ending on the
> system it runs. Thus in the case of win32 it should remove \r\n.
Hm.
template
Andre Poenitz <[EMAIL PROTECTED]> writes:
| A single char obviously can't be '\r\n'. So I'd indeed expect a '\r' at the
| end of the string read by getline(...'\n') -- unless this has something
| to do with that 'binary mode' vs 'text mode' and the \r is removed earlier.
| Somehow...
This is
On Mon, Jan 06, 2003 at 09:41:01PM +0100, Lars Gullik Bjønnes wrote:
> | A single char obviously can't be '\r\n'. So I'd indeed expect a '\r' at the
> | end of the string read by getline(...'\n') -- unless this has something
> | to do with that 'binary mode' vs 'text mode' and the \r is removed
The following patch is adapted from one of the last bits in the patch
that Claus Hentschel uses on win32. It fixes parsing of log files by
removing trailing \r.
OK to apply?
JMarc
? config.h.in
? src/ext_l10n.h
Index: src/ChangeLog
The following patch is adapted from one of the last bits in the patch
that Claus Hentschel uses on win32. It fixes parsing of log files by
removing trailing \r.
OK to apply?
JMarc
? config.h.in
? src/ext_l10n.h
Index: src/ChangeLog
68 matches
Mail list logo
