[Top][All Lists]

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

Re: race bug !?

From: Jean-Jacques Brucker
Subject: Re: race bug !?
Date: Sat, 30 Jan 2021 08:05:01 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0

Big thanks for all.

Indeed there is no bug, and IMO even nothing to improve in bash.

What put me wrong is that such erroneous command "work down" when first "xxd  -r -p | base64" output don't begin with hexadecimals characters. This happens most often, and then second "xxd  -r -p" will ignore such input.

I should have play with file descriptors and redirections to parallelize correctly.

$ echo "dc30a6d79f3b47e310b8b9f5fbadba573DCm1587" | xxd  -r -p | base64

$ echo "68b329da9893e34099c7d8ad5cb9c940" |  tee >( head -c 4 ; echo ; ls -l /proc/self/fd ) | { tee >(xxd  -r -p | basenc --base64 ) ; ls -l /proc/self/fd ; }


Le 29/01/2021 à 14:50, Chet Ramey a écrit :
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 )

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

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.

Attachment: OpenPGP_0xA3983A40D1458443.asc
Description: application/pgp-keys

Attachment: OpenPGP_signature
Description: OpenPGP digital signature

reply via email to

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