[edbrowse-dev] Processing of Windows .ebrc config file

[edbrowse-dev] Processing of Windows .ebrc config file

[Geoff McLane]

Hi Karl,

A strange, small thing, in Windows...

As normal, the first time you run edbrowse in a new machine, it creates 
a new default %APPDATA%/edbrowse/.ebrc... nothing wrong with that... 
good idea...

In Windows, the newly created file has very strange line endings, namely 
0x0d 0x0d 0x0a... again, quite puzzling, but with modern editors not 
really a problem... but...

Then every time I run edbrowse, I get a warning 
cfgLine0(MSG_EBRC_SyntaxErr) -

.ebrc: improper function definition syntax at line 125

In running the MSVC debugger, I can see the readConfigFile service gets 
very confused over the line numbering, ie the incrementing of 'ln', thus 
was not exactly able to determine which file lines it is tripping up 
over... When processing line 125, per ln, it is processing 'function+gg{ 
...'... which is line 249 according to my editor, since it counts the 
0x0D 0x0D 0x0A as two lines, so sort of agrees 125 * 2 is 250, ie about 
249...

So with these strange line endings it appears to be bombing on the first 
function in the file... but not sure...

But why do we get these strange line ending? I have seen this before... 
when outputting 0x0d 0x0a to stdout...

Ok, the source of the new file is in ebrc.c, as const char ebrc_en[], 
and the text is all in hex?! AND it already has 0x0d 0x0a line 
endings... as created by buildsourcestring.pl...

Now the new config file is opened using the 'creat' function... I assume 
the file is created in text translation mode, as opposed to binary mode, 
so when 0x0d 0x0a is written, the 0x0a is translated to 0x0d 0x0a, so we 
end up with 0x0d 0x0d 0x0a... but this is just a guess...

So this goes back to why is edrc.c written in hex... and this is back to 
buildsourcestring.pl... I note this perl scripts deliberately adds 0x0d 
0x0a if the OS is 'Win'... but why is it hexified at all... why not just 
'print OUTF  "$line\n"'

But maybe this is NOT really a problem that needs to be fixed. If I 
sanitize the file, back to standard windows CR LF line endings, the EB 
error goes away... I have a 'unix2dos' utility, called 'fixfile' - 
https://github.com/geoffmcl/fixfile - so is an easy fix...

Regards, Geoff.

Re: [edbrowse-dev] Processing of Windows .ebrc config file

[Geoff McLane]

Hi Karl,

Thanks for looking into this, and giving an explanation, a historic 
perspective...

I certainly think in the past there could have been a stupid compiler 
that limited string length, but I am pretty sure it would have died of 
old age by now... ;=))

Yes, changing main.c line 591 to 'fp = fopen(cfgfil, "wb");` - ie use 
binary mode - would do the trick... but...

But then there is line 618 'int fh = creat(configFile, MODE_private);` 
to consider, but since this is for unix, maybe no problem...

The 0x0d comes from lang\ebrc-* files, in Windows. The remote git 
repository would only use 0x0a, but depending on your git config, when 
you clone/pull, line endings are converted to native 0x0d 0x0a... but 
that is NOT where this 0x0d comes from...

See tools/buildsourcestring.pl, lines 85 - 89 - regardless of what is in 
the input file, which is stripped at line 49 - 51, with 'chomp $line; 
$line =~ s/\r*$//;', if the OS is Win type then " 0x0d, 0x0a,"; is 
appended to the hexified array...

So if you chose to keep the text mode above, you could remove that if 
($OSNAME =~ /Win/) { switch, and ONLY add " 0x0a,", as in unix...

But I am also fairly sure these days you could remove lines 83 - 89, 
etc... that is write the lines as is, in inverted commas... not convert 
it to a hexified string...

Best regards, Geoff.