From: Junio C Hamano <gitster@pobox.com>
To: Fabian Stelzer <fs@gigacodes.de>
Cc: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>,
git@vger.kernel.org, "Adam Dinwoodie" <adam@dinwoodie.org>,
"Jeff King" <peff@peff.net>
Subject: Re: [PATCH 1/2] test-lib: show missing prereq summary
Date: Mon, 15 Nov 2021 14:10:43 -0800 [thread overview]
Message-ID: <xmqqk0h9cboc.fsf@gitster.g> (raw)
In-Reply-To: <20211115195609.g6vq6qfjhyootcqt@fs> (Fabian Stelzer's message of "Mon, 15 Nov 2021 20:56:09 +0100")
Fabian Stelzer <fs@gigacodes.de> writes:
>>I am not sure '\n' is a good idea from portability perspective. I
>>thought I wrote '\012' in the illustration in my review?
>
> Yes, i was wondering why you did that. When i played around with your
> variant i used \n since it's what i commonly use and find more readable.
> And i'm by far no expert on partability. What platforms would have an
> issue with \n ?
I think I misremembered. b3b753b1 (Fit to Plan 9's ANSI/POSIX
compatibility layer, 2020-09-10) does talk about a system whose
"tr" does not fully emulate POSIX and wants an octal, but that
is not a platform we target for to begin with.
$ git grep '^[ ]*tr .*\\012['\''"]'
$ git grep '^[ ]*tr .*\\n['\''"]'
show the same number of hits, even back in v2.0.0. You have to go
back to v1.6.0 (which I consider is the oldest and still usable
release of significance) to see the source tree without any hit for
the latter. The first introduction of tr "\n" (which I consider is
a mistake---if we write octal, we do not have to worry about anybody
not supporting it) seems to be dea4562b (rerere forget path: forget
recorded resolution, 2009-12-25) made by me X-<.
next prev parent reply other threads:[~2021-11-15 22:13 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-15 16:07 [PATCH 0/2] test-lib: improve missing prereq handling Fabian Stelzer
2021-11-15 16:07 ` [PATCH 1/2] test-lib: show missing prereq summary Fabian Stelzer
2021-11-15 17:44 ` Ævar Arnfjörð Bjarmason
2021-11-15 17:53 ` Junio C Hamano
2021-11-15 19:56 ` Fabian Stelzer
2021-11-15 22:10 ` Junio C Hamano [this message]
2021-11-16 14:19 ` Fabian Stelzer
2021-11-17 8:19 ` Junio C Hamano
2021-11-17 9:05 ` Fabian Stelzer
2021-11-15 16:07 ` [PATCH 2/2] test-lib: introduce required prereq for test runs Fabian Stelzer
2021-11-16 6:09 ` Junio C Hamano
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=xmqqk0h9cboc.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=adam@dinwoodie.org \
--cc=avarab@gmail.com \
--cc=fs@gigacodes.de \
--cc=git@vger.kernel.org \
--cc=peff@peff.net \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.