Re: [PATCH] git-prompt: fix reading files with windows line endings
- From
Johannes Schindelin <johannes.schindelin@gmx.de>
- Date
- Dec 1, 2017, 10:45 UTC
- Message-ID
- <alpine.DEB.2.21.1.1712011143320.98586@virtualbox>
- In-Reply-To
- <3557a15f-3019-7d31-b990-66c2e0cb893f@robertabel.eu>
Hi Robert,
On Thu, 30 Nov 2017, Robert Abel wrote:
Show 23 quoted lines
> On 30 Nov 2017 16:21, Johannes Schindelin wrote:
> > 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.Ah. The "$@* put me on the wrong track. If you hard-code the expectation that __git_eread is not used to split tokens, maybe there should be a preparatory patch (after carefully ensuring that all callers pass only one argument) to change the "$@" to "$1"?
That will prevent future callers from expecting the token-splitting behavior that is promised by using "$@".
Ciao, Johannes