From: Robert Abel <rabel@robertabel.eu>
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] git-prompt: fix reading files with windows line endings
Date: Thu, 30 Nov 2017 07:22:04 +0100 [thread overview]
Message-ID: <cacbf41e-3b4a-99e2-a0e0-50bb4cd9e152@robertabel.eu> (raw)
In-Reply-To: <alpine.DEB.2.21.1.1711300100320.6482@virtualbox>
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:
00000000 66 6f 6f 3a 20 31 32 33 |foo: 123|
00000008
00000000 62 61 72 3a 20 34 35 36 |bar: 456|
00000008
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
00000000 66 6f 6f 3a 20 31 32 33 20 34 35 36 0d |foo:
123 456.|
0000000d
00000000 62 61 72 3a 20 |bar: |
00000005
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
next prev parent reply other threads:[~2017-11-30 6:22 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-28 20:18 git-prompt: fix reading files with windows line endings Robert Abel
2017-11-28 20:18 ` [PATCH] " Robert Abel
2017-11-29 14:27 ` Johannes Schindelin
2017-11-29 22:09 ` Robert Abel
2017-11-30 0:21 ` Johannes Schindelin
2017-11-30 6:22 ` Robert Abel [this message]
2017-11-30 15:21 ` Johannes Schindelin
2017-11-30 18:01 ` Robert Abel
2017-12-01 10:45 ` Johannes Schindelin
2017-12-01 23:31 ` [PATCH v2 1/2] git-prompt: make __git_eread intended use explicit Robert Abel
2017-12-01 23:31 ` [PATCH v2 2/2] git-prompt: fix reading files with windows line endings Robert Abel
2017-12-04 14:18 ` Johannes Schindelin
2017-12-04 17:58 ` [PATCH v2 1/2] git-prompt: make __git_eread intended use explicit Junio C Hamano
2017-12-04 22:57 ` Robert Abel
2017-12-05 0:27 ` Junio C Hamano
2017-12-05 7:01 ` Robert Abel
2017-12-05 13:06 ` Junio C Hamano
2017-12-05 23:37 ` Robert Abel
2017-12-05 23:39 ` [PATCH v4 " Robert Abel
2017-12-05 23:39 ` [PATCH v4 2/2] git-prompt: fix reading files with windows line endings Robert Abel
2017-12-04 23:49 ` [PATCH v3 1/2] git-prompt: make __git_eread intended use explicit Robert Abel
2017-12-04 23:49 ` [PATCH v3 2/2] git-prompt: fix reading files with windows line endings Robert Abel
2017-11-30 1:08 ` [PATCH] " SZEDER Gábor
2017-11-30 1:51 ` Johannes Schindelin
2017-11-30 23:45 ` SZEDER Gábor
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=cacbf41e-3b4a-99e2-a0e0-50bb4cd9e152@robertabel.eu \
--to=rabel@robertabel.eu \
--cc=Johannes.Schindelin@gmx.de \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).