From: Geoff McLane <ubuntu@geoffair.info>
To: Edbrowse-dev@lists.the-brannons.com, Karl Dahlke <eklhad@comcast.net>
Subject: [edbrowse-dev] Processing of Windows .ebrc config file
Date: Sun, 19 Jul 2020 20:57:04 +0200 [thread overview]
Message-ID: <de96b8c3-df9d-edfd-e6a2-a9b7aa68cf2c@geoffair.info> (raw)
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.
next reply other threads:[~2020-07-19 18:57 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-19 18:57 Geoff McLane [this message]
[not found] <20200619154910.eklhad@comcast.net>
2020-07-20 15:09 ` Geoff McLane
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=de96b8c3-df9d-edfd-e6a2-a9b7aa68cf2c@geoffair.info \
--to=ubuntu@geoffair.info \
--cc=Edbrowse-dev@lists.the-brannons.com \
--cc=eklhad@comcast.net \
/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 NNTP newsgroup(s).