Hi Robert,
On Thu, 30 Nov 2017, Robert Abel wrote:
> 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
