Re: Please take a look at this bug

[John McKown]

On Sun, Aug 23, 2015 at 5:42 AM, Mostafa Nazari <me@mnazari.ir> wrote:

I know why this is a bug, but this is! a bug. please inform me if there is any working around this.

#!/bin/bash

function bug_part() {

        cat $1 > sample.fisrt

        cat $1 > sample.second

}

​​

bug_part <(echo "TEST")

​​

[ "$(cat sample.fisrt)" != "$(cat sample.second)" ] && echo "THIS IS A BUG" 1>&2 && exit 1

rm sample.first sample.second

​I'm not any kind of expert, but it doesn't look like a bug to me. The function bug_part first does a "cat" of the "file" referenced by the first parameter ($1) into the file sample.fisrt. It then does a "cat" of the same "file" into sample.second. 

You then invoke bug_part() using "process redirection". The process being re-directed is: echo "TEST" . ​What then happens is that the bug_function() is invoked with a construct like /dev/fd/?? (where ?? is some number). The first "cat" in bug_part() reads this data (the entire output of the echo "TEST" process) and puts it in sample.fisrt (i.e. sample.fisrt now contains a single line of "TEST"). The first "cat" command terminates due to end of data. The second "cat" command then tries to read THE EXACT SAME file descriptor. However, this file descriptor is still sitting at "end of data" because the 'echo "TEST"' process has finished and given all its output to the first "cat" command. So the second "cat" command gets an immediate "end of data" indication and terminates. Which leaves sample.second as a 0 length file. Makes sense to me. Process redirection is _not_ exactly the same as reading a permanent file. It's more like reading a pipe or socket. The "far end" does not (necessarily) give back the same data every time.

I am guessing that you were thinking that "<(echo "TEST")" would be re-executed for each reference to "$1" in the bug_part() function? I.e. that "<(echo "TEST")" was executed and the output "kept" somewhere like some sort of temporary files. This could be emulated with something like:

x=$(mktemp) # initialize a temporary file & return its name

echo "TEST" >${x} # put data in temporary file

bug_part(${x})

​

[ "$(cat sample.fisrt)" != "$(cat sample.second)" ] && echo "THIS IS A BUG" 1>&2 && exit 1

rm sample.first sample.second

​The above is _not_ how process redirection in BASH works. ​

​If you really want a function to work "properly" in this case, you might do something like:

#!/bin/bash

function my_function() {

    x=$(cat $1) # read all the input. PERL calls this "slurping"

    echo  -n "${x}" > sample.first #put it in file

    echo  -n "${x}" > sample.second # do it again

}

​I'm really not sure if the -n switch is the right thing to do on the "echo" commands or not​

--

Schrodinger's backup: The condition of any backup is unknown until a restore is attempted.

Yoda of Borg, we are. Futile, resistance is, yes. Assimilated, you will be.

He's about as useful as a wax frying pan.

10 to the 12th power microphones = 1 Megaphone

Maranatha! <><
John McKown