bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Weird process substitution behavior


From: John Dawson
Subject: Re: Weird process substitution behavior
Date: Fri, 15 Nov 2013 06:45:51 -0600

On Fri, Nov 15, 2013 at 2:35 AM, Michael Haubenwallner <
address@hidden> wrote:

> On 11/14/2013 08:56 PM, Chet Ramey wrote:
> > On 11/8/13 6:26 PM, John Dawson wrote:
> >> The following surprised me. I thought line 4 of the output, and
> certainly
> >> line 5 of the output, should have said "0 /dev/fd/63" too. Is this
> behavior
> >> a bug?
> >
> > I'm still looking at this.  I have not had a great deal of time to
> > investigate.
>
> With named pipes (some non-Linux platforms) this does hang after the first
> line.
>
> Not sure which behaviour actually is the Right Thing though.
>

The real code this bug reduction came from actually only ran the line that
looked like line 4 (true | wc -l $1), and thus wouldn't be subject to the
expected hang with a reader opening a named pipe twice. The original code
looked more like this:

    distributed_sampler()
    {
        local formula_file=$1
        emit_sample_times --start-date $start_date --end-date $end_date
--period 5s |
            distributed_sample_formula $formula_file |
            format_samples > outfile
    }

    distributed_sampler <( here_is_a | hairy_looking_pipeline | to_emit |
a_formula )

The program distributed_sample_formula takes two files: on stdin, a list of
dates/times; in argv[1], the formula (describing the inputs and how to
compute sample values) to do sampling on. I was trying to use process
substitution to avoid writing the formula file to disk.

distributed_sample_formula was giving me those "/dev/fd/63: No such file or
directory" errors and it took a while to figure out why. Once I saw what
was going on, I was able to restructure things to avoid the issue and get
my code working. I just thought it seemed like a reasonable thing to want
to do.

John

-- 
John Dawson <address@hidden>


reply via email to

[Prev in Thread] Current Thread [Next in Thread]