On Sun, Aug 23, 2015 at 5:42 AM, Mostafa Nazari <m...@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
