From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com [IPv6:2a00:1450:4864:20::336]) by hurricane.the-brannons.com (Postfix) with ESMTPS id 2F81421DE04 for ; Sun, 19 Jul 2020 11:57:08 -0700 (PDT) Received: by mail-wm1-x336.google.com with SMTP id j18so20260763wmi.3 for ; Sun, 19 Jul 2020 11:57:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=geoffair-info.20150623.gappssmtp.com; s=20150623; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding:content-language; bh=bfSyJ97bVMrVfKDZiubkUbZw8aXs6+NzXebN+AY8dGY=; b=clS10G+oNKKZndliFhpvJHUX77tkyoDtnAstN6+kslpQHUad5byMG7TESuSEwfIc6a XXeNhsm5gaxnW5CLqlzZRNL8cMDKGzMAkVqDoVbw0QP3BF8Ds4vjha+Lq8fl2bAnnICM UryFFpb6QET4JS/D/EAbsvwnQigjNnjuiJIBtgbMDWwEl6SZzhlCPSiNUnYACSXAmrto 4+nsPnpEDGvYncz0LME+O/5Hz8uKUt3G6qpQ3jF6nqzYApg1XPBXrmZdrBOfo/13hCAB 8XAG6uuv6WjnfUO21bshAFCIQbOxnTG08GX6HdvnElR5oSc25Xczd0G/+CL+R9RiRoUj LHVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding:content-language; bh=bfSyJ97bVMrVfKDZiubkUbZw8aXs6+NzXebN+AY8dGY=; b=qGIdBuNhgndN+TbyQ8zSntcrnp+lUV7jpztUf3Cv4n82sMdyXLPRLfyMAxNdrhcJBY cJ5vAbo9QqupVm7jou0/yE05pJanjdpIJ4uILjbSjIHAvTaUAR7oaeII/2DnaSRvetV5 bfE+jh/OTgYNuWyRnAy0ywjnW8hgohpi10dTNt5cCid+IB2VIwOckN/Eurb34hOUSgVx +GQi3c4W/DuDFolE0UW3KAdBOeioBRp4y3l2pkdZ5AiNmbzygr056mrrbiHAHZtQNo5/ lTYsdEihwvVKxc8afWkNFgEDBVvfaFWOY1UXQmCIpuU659eSCSwqoozNzMJOZxRVtoPx EIjA== X-Gm-Message-State: AOAM533vw/c5ptyz8IoDIpwdVfHd6Y0tPbemYaOsb/f/AP76mxSs/ICh mbLMzIx+v5zOGGdFU6bqe36chg== X-Google-Smtp-Source: ABdhPJzskTE9CkP0U+Zpkv4UlZQC/BYXk6D9fx0fYo0X+mgIHe/DFcF6DBvI1Hh692rIFdEBQWu7dQ== X-Received: by 2002:a1c:96c5:: with SMTP id y188mr18910108wmd.71.1595185026448; Sun, 19 Jul 2020 11:57:06 -0700 (PDT) Received: from ?IPv6:2a01:cb04:4ba:c500:3839:fe4d:1ac2:f6c9? (2a01cb0404bac5003839fe4d1ac2f6c9.ipv6.abo.wanadoo.fr. [2a01:cb04:4ba:c500:3839:fe4d:1ac2:f6c9]) by smtp.googlemail.com with ESMTPSA id v11sm27833895wmb.3.2020.07.19.11.57.05 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 19 Jul 2020 11:57:05 -0700 (PDT) To: Edbrowse-dev@lists.the-brannons.com, Karl Dahlke From: Geoff McLane Subject: [edbrowse-dev] Processing of Windows .ebrc config file Message-ID: Date: Sun, 19 Jul 2020 20:57:04 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 X-BeenThere: edbrowse-dev@edbrowse.org List-Id: Edbrowse Development List MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US 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.