Re: race bug !?

[Chet Ramey]

On 1/28/21 6:33 PM, Jean-Jacques Brucker wrote:
> 100 % reproducible on my Debian, package version 5.1-2:
>
>
>
> $ echo "dc30a6d79f3b47e310b8b9f5fbadba57" | tee >( xxd  -r -p | base64) | 
> tee >(xxd  -r -p | basenc --base64url )
> dc30a6d79f3b47e310b8b9f5fbadba57
> 3DCm1587R+MQuLn1+626Vw==
> 3DCm1587R-MQuLn1-626Vz0Vhw==

Without looking at this too closely, this is always going to be somewhat
`racy', for two reasons. First, the process substitutions are executed
asynchronously, so their execution is non-deterministic. Second, the word
expansions in pipelines happen after the shell forks, and after piping is
done, so the standard output of the process substitution is the same as
the standard output of its parent: the pipe.

You can see this by using `wc' to count the lines the second pipeline 
element receives:

$ echo "dc30a6d79f3b47e310b8b9f5fbadba57" | tee >( xxd  -r -p | base64 ) | wc
       2       2      58



> I first thought I missed something about base64url encoding, after hours or 
> digging and digging documentation I tried :
>
> $ echo "dc30a6d79f3b47e310b8b9f5fbadba57" | xxd  -r -p | basenc --base64url
> 3DCm1587R-MQuLn1-626Vw==
>
>
> Those 4 extra characters "z0Vh" are quite disturbing :-/

You're not encoding the same data. You've got the original string you
echoed plus the output of the first encoding process substitution.

--
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/