[fossil-users] spurious CRLF generated by `finfo -p' (and other terminal output)

2012-12-20 Thread j. van den hoff

hi,

I accidentally noted that all terminal (stdout) output of `fossil'  
seemingly uses CRLF (\r\n) as EOL even on unix-based machines (i.e.  
everything in the world except those view machines running something else  
;-)). at least it does so under MacOSX.


I would find it more reasonable if `fossil' would adjust its EOL  
convention to that of the underlying OS. especially


`fossil finfo -p somefile.txt  acopy.txt'

is rather annoying since (assuming *CURRENT* is at the respective `leave')  
the checked out version of
`somefile.txt' is then _not_ identical to `acopy.txt' (since the latter  
has the CRLF EOLs while `somefile.txt' has not).


is this considered a bug??

if not so, could this behavior be changed nevertheless?

j.

--
Using Opera's revolutionary email client: http://www.opera.com/mail/
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users


Re: [fossil-users] spurious CRLF generated by `finfo -p' (and other terminal output)

2012-12-20 Thread Richard Hipp
On Thu, Dec 20, 2012 at 12:47 PM, j. van den hoff veedeeh...@googlemail.com
 wrote:

 hi,

 I accidentally noted that all terminal (stdout) output of `fossil'
 seemingly uses CRLF (\r\n) as EOL even on unix-based machines (i.e.
 everything in the world except those view machines running something else
 ;-)). at least it does so under MacOSX.

 I would find it more reasonable if `fossil' would adjust its EOL
 convention to that of the underlying OS. especially

 `fossil finfo -p somefile.txt  acopy.txt'


finfo does not use any EOL.  It simply outputs what is in your file.  It
treats all files as binary. If you are seeing \r characters in the output
above, that is because you checked \r characters into somefile.txt, I think.



 is rather annoying since (assuming *CURRENT* is at the respective `leave')
 the checked out version of
 `somefile.txt' is then _not_ identical to `acopy.txt' (since the latter
 has the CRLF EOLs while `somefile.txt' has not).

 is this considered a bug??

 if not so, could this behavior be changed nevertheless?

 j.

 --
 Using Opera's revolutionary email client: http://www.opera.com/mail/
 __**_
 fossil-users mailing list
 fossil-users@lists.fossil-scm.**org fossil-users@lists.fossil-scm.org
 http://lists.fossil-scm.org:**8080/cgi-bin/mailman/listinfo/**fossil-usershttp://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users




-- 
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users


Re: [fossil-users] spurious CRLF generated by `finfo -p' (and other terminal output)

2012-12-20 Thread j. van den hoff

On Thu, 20 Dec 2012 19:03:07 +0100, Richard Hipp d...@sqlite.org wrote:

On Thu, Dec 20, 2012 at 12:47 PM, j. van den hoff  
veedeeh...@googlemail.com

wrote:



hi,

I accidentally noted that all terminal (stdout) output of `fossil'
seemingly uses CRLF (\r\n) as EOL even on unix-based machines (i.e.
everything in the world except those view machines running something  
else

;-)). at least it does so under MacOSX.

I would find it more reasonable if `fossil' would adjust its EOL
convention to that of the underlying OS. especially

`fossil finfo -p somefile.txt  acopy.txt'



finfo does not use any EOL.  It simply outputs what is in your file.  It
treats all files as binary. If you are seeing \r characters in the output
above, that is because you checked \r characters into somefile.txt, I  
think.


thanks for the quick answer. you are right, there are no \r, but the  
reason is different (still my fault!): I use a wrapper script for driving  
`fossil' and _that_ script somehow injects the \r. I have to check this.


really sorry for the additional noise
j.






is rather annoying since (assuming *CURRENT* is at the respective  
`leave')

the checked out version of
`somefile.txt' is then _not_ identical to `acopy.txt' (since the latter
has the CRLF EOLs while `somefile.txt' has not).

is this considered a bug??

if not so, could this behavior be changed nevertheless?

j.

--
Using Opera's revolutionary email client: http://www.opera.com/mail/
__**_
fossil-users mailing list
fossil-users@lists.fossil-scm.**org fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:**8080/cgi-bin/mailman/listinfo/**fossil-usershttp://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users








--
Using Opera's revolutionary email client: http://www.opera.com/mail/
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users