error: Broken pipe
W:bin/iotest: line 112: /dev/fd/62: No such file or directory
/h> cat: write error: Broken pipe
---
Regardless of implementation, this has worked for the past
3 years (1st checked in 2014-10-29) with the coalesce receive
microseconds set to 1. Only when I change rx-us
rror: Broken pipe
> W:bin/iotest: line 112: /dev/fd/62: No such file or directory
> /h> cat: write error: Broken pipe
On Tue, Oct 17, 2017 at 1:37 PM, Ángel wrote:
> bash converts < <( dd_need_io "$if" "$of" ...) into a read
> from /dev/fd/62 in order to make readarray read file descriptor 62.
>
> Given that this the host OS doesn't provide them, the first thing I
> would verify would be: is cygwin, as setup
timings of file transfer speed, APART from
> file-io delays of going through the file system.
(...)
> So my question is -- how can the pipe disappear so fast
> that my "readarray out" results in a broken pipe message.
>
> Shouldn't that be impossible with the code above
gs of file transfer speed, APART from
file-io delays of going through the file system.
In going to '0', I'm now getting:
/h> bin/iotest
Using bs=4.0M, count=4, iosize=16.0M
R:bin/iotest: line 112: /dev/fd/62: No such file or directory
cat: write error: Broken pipe
W:bin/iotest: line 112:
"Brian J. Murrell" <[EMAIL PROTECTED]> wrote:
> It is a shame for this particular reason that head does not (perhaps as
> an option) consume it's input after displaying the 20 lines.
You can do that with sed:
... | sed '21,$d'
paul
On Wed, 2008-02-13 at 16:00 -0500, Brian J. Murrell wrote:
>
> find / -type f -print 2>&1 | head -20 || true
Doh!
This of course won't work. The first solution should though.
b.
signature.asc
Description: This is a digitally signed message part
On Wed, 2008-02-13 at 14:56 -0600, Michael Potter wrote:
> Bash Bunch,
>
> I googled a bit and it see this problem asked several times, but I
> never really saw a slick solution:
>
> given this:
>
> set -o pipefail
> find / -type f -print 2>&1 |head -20
> echo ${PIPESTATUS[*]}
>
> prints this:
Bash Bunch,
I googled a bit and it see this problem asked several times, but I
never really saw a slick solution:
given this:
set -o pipefail
find / -type f -print 2>&1 |head -20
echo ${PIPESTATUS[*]}
prints this:
141 0
find fails because it has a bunch of output, but head only will accept
the
> Chet Ramey <[EMAIL PROTECTED]> wrote:
> > `echo' now displays an error message on write errors.
>
> In the case of a SIGPIPE trap, is it intended that echo sees EPIPE
> before the SIGPIPE handler runs?
Yes. POSIX requires that trap handling be deferred until a `foreground
utility' completes, a
Chet Ramey <[EMAIL PROTECTED]> wrote:
> `echo' now displays an error message on write errors.
In the case of a SIGPIPE trap, is it intended that echo sees EPIPE
before the SIGPIPE handler runs?
paul
___
Bug-bash mailing list
Bug-bash@gnu.org
http://l
> If there is no trap set it doesn't report an error. So is this
> special behaviour only triggered when there is a trap for SIGPIPE in
> place?
It's not `special', except maybe in the sense that catching a signal
rather than letting it terminate the process causes writes to return
errors.
Chet
On Mon, Jan 09, 2006 at 02:22:11PM -0500, Chet Ramey wrote:
> > bash-3.1:
> >
> > $ bash -c 'trap exit SIGPIPE; echo foo' | :
> > bash: line 0: echo: write error: Broken pipe
> > $
> >
> > Is this change in behaviour intentional, or a
gt;
> bash-3.1:
>
> $ bash -c 'trap exit SIGPIPE; echo foo' | :
> bash: line 0: echo: write error: Broken pipe
> $
>
> Is this change in behaviour intentional, or a regression?
It's intentional, and doesn't have anything to do with job control
or processe
27; | :
bash: line 0: echo: write error: Broken pipe
$
Is this change in behaviour intentional, or a regression?
Original bug report:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177242
Thanks,
Tim.
*/
pgprpHnWZKsa0.pgp
Description: PGP signature
15 matches
Mail list logo
