[PATCH v4 2/2] git-prompt: fix reading files with windows line endings
If any of the files read by __git_eread have \r\n line endings, read
will only strip \n, leaving \r. This results in an ugly prompt, where
instead of
user@pc MINGW64 /path/to/repo (BARE:master)
the last parenthesis is printed over the beginning of the prompt like
)ser@pc MINGW64 /path/to/repo (BARE:master
This patch fixes the issue by changing the internal field separator
variable IFS to $'\r\n' before using the read builtin command.
Note that ANSI-C Quoting/POSIX Quoting ($'...') is supported by bash
as well as zsh, which are the current targets of git-prompt, cf.
contrib/completion/git-prompt.sh.
Signed-off-by: Robert Abel <ra...@robertabel.eu>
---
contrib/completion/git-prompt.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh
index 41a471957a..983e419d2b 100644
--- a/contrib/completion/git-prompt.sh
+++ b/contrib/completion/git-prompt.sh
@@ -283,7 +283,7 @@ __git_ps1_colorize_gitstring ()
# variable, in that order.
__git_eread ()
{
- test -r "$1" && read "$2" <"$1"
+ test -r "$1" && IFS=$'\r\n' read "$2" <"$1"
}
# __git_ps1 accepts 0 or 1 arguments (i.e., format string)
--
2.13.0.windows.1
[PATCH v4 1/2] git-prompt: make __git_eread intended use explicit
__git_eread is used to read a single line of a given file (if it exists)
into a single variable stripping the EOL.
This patch removes the unused capability to split file contents into tokens
by passing multiple variable names. Add a comment and explicitly use $2
instead of misleading $@ as argument to the read builtin command.
Signed-off-by: Robert Abel <ra...@robertabel.eu>
---
contrib/completion/git-prompt.sh | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh
index c6cbef38c2..41a471957a 100644
--- a/contrib/completion/git-prompt.sh
+++ b/contrib/completion/git-prompt.sh
@@ -278,11 +278,12 @@ __git_ps1_colorize_gitstring ()
r="$c_clear$r"
}
+# Helper function to read the first line of a file into a variable.
+# __git_eread requires 2 arguments, the file path and the name of the
+# variable, in that order.
__git_eread ()
{
- local f="$1"
- shift
- test -r "$f" && read "$@" <"$f"
+ test -r "$1" && read "$2" <"$1"
}
# __git_ps1 accepts 0 or 1 arguments (i.e., format string)
--
2.13.0.windows.1
Re: [PATCH v2 1/2] git-prompt: make __git_eread intended use explicit
Dear Junio, I'm amazed at how much time and energy you spend on correcting these essentially non-issues in my git commit messages for a quadruple-liner code change. I'll resend both patches one last time addressing the grave issue of the informative mention of multi-line files. Regards, Robert
Re: [PATCH v2 1/2] git-prompt: make __git_eread intended use explicit
Hi Junio, On 05 Dec 2017 01:27, Junio C Hamano wrote: > I know all of the above, but I think you misunderstood the point I > wanted to raise, so let me try again. The thing is, none of what > you just wrote changes the fact that lack of callers that want to do > "multi-line" is IRRELEVANT. I disagree. The commit comment is meant to give context to the introduced changes. One change is the additional comment for __git_eread, which now clearly states that only a single line is read. I'm well aware that I'm not breaking reading multiple lines, because that never worked in the first place. Thus, it was never the indented use for __git_eread as I see it. I explicitly want to include that information in my commit message to pay it forward to the next person working on the prompt. Regards, Robert
[PATCH v3 1/2] git-prompt: make __git_eread intended use explicit
__git_eread is used to read a single line of a given file (if it exists)
into a single variable without the EOL. All six current users of __git_eread
use it that way and don't expect multi-line content.
Therefore, this patch removes the unused capability to split file conents into
tokens by passing multiple variable names. Add a comment and explicitly use $2
instead of $@ to read the file into one variable.
Signed-off-by: Robert Abel <ra...@robertabel.eu>
---
contrib/completion/git-prompt.sh | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh
index c6cbef38c2..41a471957a 100644
--- a/contrib/completion/git-prompt.sh
+++ b/contrib/completion/git-prompt.sh
@@ -278,11 +278,12 @@ __git_ps1_colorize_gitstring ()
r="$c_clear$r"
}
+# Helper function to read the first line of a file into a variable.
+# __git_eread requires 2 arguments, the file path and the name of the
+# variable, in that order.
__git_eread ()
{
- local f="$1"
- shift
- test -r "$f" && read "$@" <"$f"
+ test -r "$1" && read "$2" <"$1"
}
# __git_ps1 accepts 0 or 1 arguments (i.e., format string)
--
2.13.0.windows.1
[PATCH v3 2/2] git-prompt: fix reading files with windows line endings
If any of the files read by __git_eread have \r\n line endings, read
will only strip \n, leaving \r. This results in an ugly prompt, where
instead of
user@pc MINGW64 /path/to/repo (BARE:master)
the last parenthesis is printed over the beginning of the prompt like
)ser@pc MINGW64 /path/to/repo (BARE:master
This patch fixes the issue by setting the IFS to $'\r\n' for the read
operation. Note that ANSI-C Quoting ($'...') is supported by bash as
well as zsh, which are the current targets of git-prompt.sh, cf.
<20171130010811.17369-1-szeder@gmail.com>.
Signed-off-by: Robert Abel <ra...@robertabel.eu>
---
contrib/completion/git-prompt.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh
index 41a471957a..983e419d2b 100644
--- a/contrib/completion/git-prompt.sh
+++ b/contrib/completion/git-prompt.sh
@@ -283,7 +283,7 @@ __git_ps1_colorize_gitstring ()
# variable, in that order.
__git_eread ()
{
- test -r "$1" && read "$2" <"$1"
+ test -r "$1" && IFS=$'\r\n' read "$2" <"$1"
}
# __git_ps1 accepts 0 or 1 arguments (i.e., format string)
--
2.13.0.windows.1
Re: [PATCH v2 1/2] git-prompt: make __git_eread intended use explicit
Hi Junio, On 04 Dec 2017 18:58, Junio C Hamano wrote: > Robert Abel <ra...@robertabel.eu> writes: >> __git_eread is used to read a single line of a given file (if it exists) >> into a variable without the EOL. All six current users of __git_eread >> use it that way and don't expect multi-line content. > > Changing $@ to $2 does not change whether this is about "multi-line" > or not. I'm aware of that. I was documenting current usage. The function is used to read file contents (which are expected to be a single line) into _a_ (i.e. single) variable. None of the current users of the function expect tokens to be split, which is why I removed it in preparation of patch 2/2, which would break tokenizing file contents. Regards, Robert
[PATCH v2 1/2] git-prompt: make __git_eread intended use explicit
__git_eread is used to read a single line of a given file (if it exists)
into a variable without the EOL. All six current users of __git_eread
use it that way and don't expect multi-line content.
Thus, add a comment and explicitly use $2 instead of shifting the args
down and using $@.
Signed-off-by: Robert Abel <ra...@robertabel.eu>
---
contrib/completion/git-prompt.sh | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh
index c6cbef38c..41a471957 100644
--- a/contrib/completion/git-prompt.sh
+++ b/contrib/completion/git-prompt.sh
@@ -278,11 +278,12 @@ __git_ps1_colorize_gitstring ()
r="$c_clear$r"
}
+# Helper function to read the first line of a file into a variable.
+# __git_eread requires 2 arguments, the file path and the name of the
+# variable, in that order.
__git_eread ()
{
- local f="$1"
- shift
- test -r "$f" && read "$@" <"$f"
+ test -r "$1" && read "$2" <"$1"
}
# __git_ps1 accepts 0 or 1 arguments (i.e., format string)
--
2.15.1
[PATCH v2 2/2] git-prompt: fix reading files with windows line endings
If any of the files read by __git_eread have \r\n line endings, read
will only strip \n, leaving \r. This results in an ugly prompt, where
instead of
user@pc MINGW64 /path/to/repo (BARE:master)
the last parenthesis is printed over the beginning of the prompt like
)ser@pc MINGW64 /path/to/repo (BARE:master
Signed-off-by: Robert Abel <ra...@robertabel.eu>
---
contrib/completion/git-prompt.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh
index 41a471957..983e419d2 100644
--- a/contrib/completion/git-prompt.sh
+++ b/contrib/completion/git-prompt.sh
@@ -283,7 +283,7 @@ __git_ps1_colorize_gitstring ()
# variable, in that order.
__git_eread ()
{
- test -r "$1" && read "$2" <"$1"
+ test -r "$1" && IFS=$'\r\n' read "$2" <"$1"
}
# __git_ps1 accepts 0 or 1 arguments (i.e., format string)
--
2.15.1
[PATCH] l10n: update de_DE translation
Der-, die- and dasselbe and their declensions are spelt as one word in German. Signed-off-by: Robert Abel <ra...@robertabel.eu> --- po/de.po | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/po/de.po b/po/de.po index a05aca5f3..400262625 100644 --- a/po/de.po +++ b/po/de.po @@ -2925,7 +2925,7 @@ msgstr " (benutzen Sie \"git branch --unset-upstream\" zum Beheben)\n" #: remote.c:2083 #, c-format msgid "Your branch is up to date with '%s'.\n" -msgstr "Ihr Branch ist auf dem selben Stand wie '%s'.\n" +msgstr "Ihr Branch ist auf demselben Stand wie '%s'.\n" #: remote.c:2087 #, c-format @@ -10874,7 +10874,7 @@ msgstr "Kann nicht überschreiben" #: builtin/mv.c:239 msgid "multiple sources for the same target" -msgstr "mehrere Quellen für das selbe Ziel" +msgstr "mehrere Quellen für dasselbe Ziel" #: builtin/mv.c:241 msgid "destination directory does not exist" @@ -11827,7 +11827,7 @@ msgstr "" "\n" "git push %s HEAD:%s\n" "\n" -"Um auf den Branch mit dem selben Namen im Remote-Repository zu versenden,\n" +"Um auf den Branch mit demselben Namen im Remote-Repository zu versenden,\n" "benutzen Sie:\n" "\n" "git push %s %s\n" -- 2.15.1
Re: [PATCH] git-prompt: fix reading files with windows line endings
Hi Johannes,
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.
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
Re: [PATCH] git-prompt: fix reading files with windows line endings
Hi Johannes,
On 30 Nov 2017 01:21, Johannes Schindelin wrote:
> On Wed, 29 Nov 2017, Robert Abel wrote:
>> This means that it should be okay to just do
>>
>>> test -r "$f" && IFS=" \t\r\n" read "$@" < "$f"
>
> I am afraid that this won't work: when I call
I managed to trick myself with that one, yes...
Apparently I had already converted my HEAD back to Unix line endings.
However, I noticed that the behavior of read is apparently
ambiguous for the last (or a single) variable:
>From POSIX.1-2008:
> If there are fewer vars than fields, the last var shall be set to a
> value comprising the following elements:
> - The field that corresponds to the last var in the normal assignment
> sequence described above
> - The delimiter(s) that follow the field corresponding to the last var
> - The remaining fields and their delimiters, with trailing IFS white
> space ignored
I read that last "ignored" as "trailing IFS white space shall not be
appended". Apparently, people implementing read read it as "trailing
IFS while space shall not be processed further"
Thus, the behavior for trailing IFS white space is different in
case of one or two variables:
printf '123 456\r\n' | while IFS=$' \t\r\n' read foo bar
do
printf 'foo: %s' "$foo" | hexdump -C
printf 'bar: %s' "$bar" | hexdump -C
done
This works as expected trimming the trailing \r:
66 6f 6f 3a 20 31 32 33 |foo: 123|
0008
62 61 72 3a 20 34 35 36 |bar: 456|
0008
While doing the same just reading a single variable
printf '123 456\r\n' | while IFS=$' \t\r\n' read foo
do
printf 'foo: %s' "$foo" | hexdump -C
printf 'bar: %s' "$bar" | hexdump -C
done
prints
66 6f 6f 3a 20 31 32 33 20 34 35 36 0d |foo:
123 456.|
000d
62 61 72 3a 20|bar: |
0005
Notice the 0d at the end of foo, which didn't get trimmed.
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.
Regards,
Robert
Re: [PATCH] git-prompt: fix reading files with windows line endings
Hi Johannes,
On 29 Nov 2017 15:27, Johannes Schindelin wrote:
>> diff --git a/contrib/completion/git-prompt.sh
>> b/contrib/completion/git-prompt.sh
>> index c6cbef38c2..71a64e7959 100644
>> --- a/contrib/completion/git-prompt.sh
>> +++ b/contrib/completion/git-prompt.sh
>> @@ -282,7 +282,7 @@ __git_eread ()
>> {
>> local f="$1"
>> shift
>> -test -r "$f" && read "$@" <"$f"
>> +test -r "$f" && read "$@" <"$f" && export $@="${!@%$'\r'}"
>
> As far as I understand, $'\r' is a Bash-only construct, and this file
> (git-prompt.sh) is targeting other Unix shells, too.
Sorry, I wasn't really aware about this bash-ism. I agree that a generic
solution would be best.
> So how about using `tr -d '\r' <"$f" | read "$@"` instead?
That doesn't work for me. Apparently, the variable is always reset to ""
and hence the prompt will always display the shortened sha1.
Maybe it has something to do with variable scoping inside the backtick
evaluation?
> Or maybe keep with the Bash construct, but guarded behind a test that we
> area actually running in Bash? Something like
>
> test -z "$BASH" || IFS=$' \t\r\n'
Actually, this got me thinking and reading the POSIX.1-2008, specifically
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/read.html.
It seems POSIX states that IFS should be supported by read. This means
that it should be okay to just do
> test -r "$f" && IFS=" \t\r\n" read "$@" < "$f"
This would also get rid of the export and avoid introducing backtick
evaluation.
Regards,
Robert
[PATCH] git-prompt: fix reading files with windows line endings
If any of the files read by __git_eread have \r\n line endings, read
will only strip \n, leaving \r. This results in an ugly prompt, where
instead of
user@pc MINGW64 /path/to/repo (BARE:master)
the last parenthesis is printed over the beginning of the prompt like
)ser@pc MINGW64 /path/to/repo (BARE:master
Signed-off-by: Robert Abel <ra...@robertabel.eu>
---
contrib/completion/git-prompt.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh
index c6cbef38c2..71a64e7959 100644
--- a/contrib/completion/git-prompt.sh
+++ b/contrib/completion/git-prompt.sh
@@ -282,7 +282,7 @@ __git_eread ()
{
local f="$1"
shift
- test -r "$f" && read "$@" <"$f"
+ test -r "$f" && read "$@" <"$f" && export $@="${!@%$'\r'}"
}
# __git_ps1 accepts 0 or 1 arguments (i.e., format string)
--
2.13.0.windows.1
git-prompt: fix reading files with windows line endings
I noticed today that my git prompt using msys-git on Windows got a bit broken. After investigating I found that the git-prompt doesn't handle the case when __git_eread reads Windows line endings \r\n. It will only strip \n, leaving the \r. I noticed this when I created a repository with msys-git, did some tasks and later wanted to check the bare. Apparently, another tool on my PC went wild and replaced all line endings in all text files it could find, breaking my git prompt.
