[Bug 2138315] [NEW] comm does not work as expected with process substitution

[Michel Decima]

Public bug reported:

comm does not work as expected with process substitution

Command "comm" from rust-coreutils works differently depending on
whether it is invoked with files or process substitutions. With the
"comm" from gnu-coreutils, there is no differences.

Summary:

Using Rust 'comm', for some file A and B, each containing sorted
elements, the result of 'comm A B' is different of that of 'comm <(cat
A) <(cat B)' whereas we would expect an identical result.

Obviously, in real life, we wouldn't use 'cat' but rather 'sort', as in
'comm <(sort A) <(sort B), but I prefer to use 'cat' to show that the
problem is indeed in 'comm' and not in 'sort'.

Environment:

$ comm --version
comm (uutils coreutils) 0.2.2
$ sort --version
sort (uutils coreutils) 0.2.2

Steps to reproduce:

1. create a file A containing only the string 00000, and a second file B
containing all integers between 1 and 10000, 5 characters wide, padded
on the left with zeros, one per line :

$ echo 00000 > A
$ seq --format '%05.0f' 10000 > B

Both files are obviously sorted, but let's check anyway:

$ sort --check A && sort --check B && echo OK
OK

2. Search all lines from file A that are not in file B using "comm",
expected result is a single line containing 00000 :

$ comm -23 A B
00000

of course we have the same result with GNU comm :

$ gnucomm -23 A B
00000

3. Repeat the previous step, replacing the raw files with process
substitutions. The expected result is still 00000 on a single line.

$ comm -23 <(cat A) <(cat B) && echo OK
00000
comm: file 2 is not in sorted order
comm: input is not in sorted order

Output is correct but exit status is no longer 0, and comm complains
with input orderning, which is obviously false.

Using GNU comm, everything is fine with process substitutions :

$ gnucomm -23 <(cat A) <(cat B) && echo OK
00000
OK

4. The value of 10,000 previously used was selected at random. The
minimum value at which the behavior changes can be easily determined.

$ for ((i=1;i<=10000;i++)) do comm -23 <(echo 00000) <(seq --format '%05.0f' $i) || break ; done > /dev/null
comm: file 2 is not in sorted order
comm: input is not in sorted order
$ echo $i
1366

So we have correct operation up to 1365 :

$ comm -23 <(echo 00000) <(seq --format '%05.0f' 1365) && echo OK
00000
OK

but from 1366 onwards, the behavior changes :

$ comm -23 <(echo 00000) <(seq --format '%05.0f' 1366) && OK
00000
comm: file 2 is not in sorted order
comm: input is not in sorted order

Of course, there should be no difference, as the GNU version of comm
does.


More environment details : 

$ lsb_release -rd
Description:	Ubuntu 25.10
Release:	25.10

$ lsb_release -rd
Description:	Ubuntu 25.10
Release:	25.10

$ apt-cache policy rust-coreutils gnu-coreutils
rust-coreutils:
  Installé : 0.2.2-0ubuntu2.1
  Candidat : 0.2.2-0ubuntu2.1
 Table de version :
 *** 0.2.2-0ubuntu2.1 500
        500 http://archive.ubuntu.com/ubuntu questing-updates/main amd64 Packages
        500 http://archive.ubuntu.com/ubuntu questing-security/main amd64 Packages
        100 /var/lib/dpkg/status
     0.2.2-0ubuntu2 500
        500 http://archive.ubuntu.com/ubuntu questing/main amd64 Packages
gnu-coreutils:
  Installé : 9.5-1ubuntu4
  Candidat : 9.5-1ubuntu4
 Table de version :
 *** 9.5-1ubuntu4 500
        500 http://archive.ubuntu.com/ubuntu questing/main amd64 Packages
        100 /var/lib/dpkg/status

** Affects: rust-coreutils (Ubuntu)
     Importance: Undecided
         Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to rust-coreutils in Ubuntu.
https://bugs.launchpad.net/bugs/2138315

Title:
  comm does not work as expected with process substitution

Status in rust-coreutils package in Ubuntu:
  New

Bug description:
  comm does not work as expected with process substitution

  Command "comm" from rust-coreutils works differently depending on
  whether it is invoked with files or process substitutions. With the
  "comm" from gnu-coreutils, there is no differences.

  Summary:

  Using Rust 'comm', for some file A and B, each containing sorted
  elements, the result of 'comm A B' is different of that of 'comm <(cat
  A) <(cat B)' whereas we would expect an identical result.

  Obviously, in real life, we wouldn't use 'cat' but rather 'sort', as
  in 'comm <(sort A) <(sort B), but I prefer to use 'cat' to show that
  the problem is indeed in 'comm' and not in 'sort'.

  Environment:

  $ comm --version
  comm (uutils coreutils) 0.2.2
  $ sort --version
  sort (uutils coreutils) 0.2.2

  Steps to reproduce:

  1. create a file A containing only the string 00000, and a second file
  B containing all integers between 1 and 10000, 5 characters wide,
  padded on the left with zeros, one per line :

  $ echo 00000 > A
  $ seq --format '%05.0f' 10000 > B

  Both files are obviously sorted, but let's check anyway:

  $ sort --check A && sort --check B && echo OK
  OK

  2. Search all lines from file A that are not in file B using "comm",
  expected result is a single line containing 00000 :

  $ comm -23 A B
  00000

  of course we have the same result with GNU comm :

  $ gnucomm -23 A B
  00000

  3. Repeat the previous step, replacing the raw files with process
  substitutions. The expected result is still 00000 on a single line.

  $ comm -23 <(cat A) <(cat B) && echo OK
  00000
  comm: file 2 is not in sorted order
  comm: input is not in sorted order

  Output is correct but exit status is no longer 0, and comm complains
  with input orderning, which is obviously false.

  Using GNU comm, everything is fine with process substitutions :

  $ gnucomm -23 <(cat A) <(cat B) && echo OK
  00000
  OK

  4. The value of 10,000 previously used was selected at random. The
  minimum value at which the behavior changes can be easily determined.

  $ for ((i=1;i<=10000;i++)) do comm -23 <(echo 00000) <(seq --format '%05.0f' $i) || break ; done > /dev/null
  comm: file 2 is not in sorted order
  comm: input is not in sorted order
  $ echo $i
  1366

  So we have correct operation up to 1365 :

  $ comm -23 <(echo 00000) <(seq --format '%05.0f' 1365) && echo OK
  00000
  OK

  but from 1366 onwards, the behavior changes :

  $ comm -23 <(echo 00000) <(seq --format '%05.0f' 1366) && OK
  00000
  comm: file 2 is not in sorted order
  comm: input is not in sorted order

  Of course, there should be no difference, as the GNU version of comm
  does.

  
  More environment details : 

  $ lsb_release -rd
  Description:	Ubuntu 25.10
  Release:	25.10

  $ lsb_release -rd
  Description:	Ubuntu 25.10
  Release:	25.10

  $ apt-cache policy rust-coreutils gnu-coreutils
  rust-coreutils:
    Installé : 0.2.2-0ubuntu2.1
    Candidat : 0.2.2-0ubuntu2.1
   Table de version :
   *** 0.2.2-0ubuntu2.1 500
          500 http://archive.ubuntu.com/ubuntu questing-updates/main amd64 Packages
          500 http://archive.ubuntu.com/ubuntu questing-security/main amd64 Packages
          100 /var/lib/dpkg/status
       0.2.2-0ubuntu2 500
          500 http://archive.ubuntu.com/ubuntu questing/main amd64 Packages
  gnu-coreutils:
    Installé : 9.5-1ubuntu4
    Candidat : 9.5-1ubuntu4
   Table de version :
   *** 9.5-1ubuntu4 500
          500 http://archive.ubuntu.com/ubuntu questing/main amd64 Packages
          100 /var/lib/dpkg/status

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/rust-coreutils/+bug/2138315/+subscriptions