[fpc-pascal] String literals and code page of .pas source file

[Benito van der Zander]

Hi,

>
> I would definitely keep it that way.
>
> As I see it: Redirection or not should not matter, the system should 
> assume console output.
> Things like 'tee' make this concept dubious in any case:
>
> If you pipe output to a program, you don't expect the codepage to change
> because of the redirection. 


In my projects, I set the output codepage to utf-8 when there is a 
redirection

It is platform agnostic, on identical inputs, it creates identical 
output files on Linux and Windows. No one needs OEM files on Linux

Best,
Benito

On 14.09.2020 14:51, Michael Van Canneyt via fpc-pascal wrote:
>
>
> On Mon, 14 Sep 2020, Tomas Hajny via fpc-pascal wrote:
>
>>> opened:
>>> {$ifdef FPC_HAS_FEATURE_ANSISTRINGS}
>>>   { if no codepage is yet assigned then assign default ansi codepage }
>>> TextRec(t).CodePage:=TranslatePlaceholderCP(TextRec(t).CodePage);
>>> {$else FPC_HAS_FEATURE_ANSISTRINGS}
>>>
>>> I see no need to change this ?
>>
>> Please, have a look at OpenStdIO (implemented at the end of 
>> text.inc). That one changes the default codepage for Input, Output 
>> and StdErr, but it doesn't care about possible redirection and/or 
>> piping to some other application (not necessarily written in FPC). 
>> That approach has both advantages and disadvantages. The advantage is 
>> that "type <redirected_file>" will give correct results on the 
>> console. The disadvantage is that opening the redirected file with 
>> any Win32 GUI application (let's say notepad.exe) will result in 
>> garbage.  I don't say that it is necessarily bad, but it should be 
>> documented at least if we want to keep it that way.
>
> I would definitely keep it that way.
>
> As I see it: Redirection or not should not matter, the system should 
> assume console output.
> Things like 'tee' make this concept dubious in any case:
>
> If you pipe output to a program, you don't expect the codepage to change
> because of the redirection.
>
>
>>> I think it will differ since Crt is not codepage aware. If you want 
>>> it to
>>> work the same you'll have to make Crt codepage (and hence unicode) 
>>> aware.
>>
>> As mentioned by me, Crt is currently more codepage aware than the 
>> System unit output as far as output to console is concerned, because 
>> Crt provides correct output even for shortstrings (unlike the System 
>> unit).
>
> I would need to check the details, but that sounds more like 
> accidental behaviour as opposed to intended behaviour to me :-)
>
> Michael.
> _______________________________________________
> fpc-pascal maillist  - fpc-pascal at lists.freepascal.org
> https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-pascal/attachments/20200915/e72486b5/attachment.htm>