Re: [PATCH] git-prompt: fix reading files with windows line endings

From: Robert Abel <rabel@robertabel.eu>
Date: Nov 30, 2017, 18:01 UTC
Message-ID: <3557a15f-3019-7d31-b990-66c2e0cb893f@robertabel.eu>
In-Reply-To: <alpine.DEB.2.21.1.1711301619590.6482@virtualbox>

Hi Johannes,

On 30 Nov 2017 16:21, Johannes Schindelin wrote:

Show 18 quoted lines

> On Thu, 30 Nov 2017, Robert Abel wrote:
>> So reading a dummy variable along with the actual content variable
>> works for git-prompt:
>>
>>     __git_eread ()
>>     {
>>         local f="$1"
>>         local dummy
>>         shift
>>         test -r "$f" && IFS=$'\r\n' read "$@" dummy < "$f"
>>     }
>>
>> I feel like this would be the most readable solution thus far.
> 
> Hmm. I am just a little concerned about "dummy" swallowing the rest of the
> line, e.g. when reading "1 2 3" via `__git_eread line`... the way I read
> it, dummy would consume "2 3" and line would *not* receive "1 2 3" but
> only "1"...

You missed that tab and space aren't field separator anymore, because IFS=$'\r\n'. The way I see it, __git_eread was never meant to split tokens. Its primary purpose was to test if a file exists and if so, read all its contents sans the newline into a variable.

That's how all call to __git_eread use it. And none of them are equipped to handle multi-line file contents or want to read more than one variable.

So this version does exactly that, but for CRLF line endings, too. I successfully use the above version now on two of my PCs.

If you agree and nobody else has any concerns, I'll resend an edited patch to accomodate for the changes and probably put a comment with usage info above __git_eread.

Regards,

Robert