From: "Randall S. Becker" <rsbecker@nexbridge.com>
To: "'Jeff King'" <peff@peff.net>
Cc: "'Junio C Hamano'" <gitster@pobox.com>, <git@vger.kernel.org>,
"'Linux Kernel'" <linux-kernel@vger.kernel.org>,
<git-packagers@googlegroups.com>
Subject: RE: [Breakage] Git v2.21.0-rc0 - t5318 (NonStop)
Date: Fri, 8 Feb 2019 14:26:17 -0500 [thread overview]
Message-ID: <002b01d4bfe4$2d617f40$88247dc0$@nexbridge.com> (raw)
In-Reply-To: <20190208191519.GF27673@sigill.intra.peff.net>
On February 8, 2019 14:15, Jeff King wrote:
> On Fri, Feb 08, 2019 at 01:47:04PM -0500, Randall S. Becker wrote:
>
> > > Though I suspect we may be able to just find a solution that works
> > > everywhere, without having two different implementations. If we know
> > > we need $count bytes for dd, we could probably just generate a file
> > > with that many NULs in it.
> >
> > For this, we could use truncate -s count file instead of dd to get a
> > fixed size file of nulls. This would remove the need for /dev/zero in
> > t5318 (the patch below probably will wrap badly in my mailer so I can
> > submit a real patch separately.
>
> I don't think "truncate" is portable, though.
It is available AFAIK on Linux, POSIX, and Windows under Cygwin. That's more than /dev/zero has anyway. I have the patch ready if you want it.
> > > Other cases don't seem to actually care that they're getting NULs,
> > > and are just redirecting stdin from /dev/zero to get an infinite
> > > amount of input. They could probably use "yes" for that.
> >
> > What about reading from /dev/null?
>
> That would yield zero bytes, not an infinite number of them.
So something like: yes | tr 'y' '\0' | stuff?
next prev parent reply other threads:[~2019-02-08 19:26 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-08 11:08 [Breakage] Git v2.21.0-rc0 - t5318 (NonStop) Randall S. Becker
2019-02-08 16:50 ` Jeff King
2019-02-08 17:49 ` Randall S. Becker
2019-02-08 18:03 ` Jeff King
2019-02-08 18:29 ` Johannes Sixt
2019-02-08 19:31 ` Junio C Hamano
2019-02-08 18:47 ` Randall S. Becker
2019-02-08 19:15 ` Jeff King
2019-02-08 19:26 ` Randall S. Becker [this message]
2019-02-08 19:31 ` Jeff King
2019-02-08 20:38 ` Randall S. Becker
2019-02-08 21:00 ` Jeff King
2019-02-08 21:44 ` Randall S. Becker
2019-02-08 22:07 ` brian m. carlson
2019-02-08 22:12 ` Randall S. Becker
2019-02-08 22:18 ` brian m. carlson
2019-02-08 22:36 ` Randall S. Becker
2019-02-08 22:35 ` Jeff King
2019-02-08 22:53 ` Randall S. Becker
2019-02-09 4:24 ` Jeff King
2019-02-09 8:39 ` Johannes Sixt
2019-02-09 16:55 ` Randall S. Becker
2019-02-09 23:29 ` Jeff King
2019-02-10 9:40 ` Johannes Sixt
2019-02-09 16:53 ` Randall S. Becker
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='002b01d4bfe4$2d617f40$88247dc0$@nexbridge.com' \
--to=rsbecker@nexbridge.com \
--cc=git-packagers@googlegroups.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=linux-kernel@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.