Comment 5 for bug 1913729

Since all systems I've used didn't trigger it I wondered how common this case is.

Could you run it like:
  sudo bash -x /usr/bin/rescan-scsi-bus.sh -i

That should show you which devices are the ones triggering it for you.
Before the error there is a call to
    sg_turs /dev/$SGDEV >/dev/null 2>&1

That should have some odd RC codes that lead to the issue.

I was fetching a system with actual LUNs and then executed the new and old version.

New
...
+ SGDEV=sg19
+ test -z sg19
+ sg_turs /dev/sg19
+ RC=0
+ test 0 = 2 -o 0 = 6
+ test 0 '!=' 0
+ test 0 = 1
+ RC=0
++ sg_inq --len=36 /dev/sg19
...

New:
 Scanning for device 1 0 1 1076117540 ...
OLD: Host: scsi1 Channel: 00 Id: 01 Lun: 1076117540
      Vendor: IBM Model: 2107900 Rev: 2700
      Type: Direct-Access ANSI SCSI revision: 05
0 new or changed device(s) found.
0 remapped or resized device(s) found.
0 device(s) removed.

old:
...
      Type: Direct-Access ANSI SCSI revision: 05
./rescan-scsi-bus.sh: line 257: test: !=: unary operator expected
 Scanning for device 1 0 1 1076117540 ...
OLD: Host: scsi1 Channel: 00 Id: 01 Lun: 1076117540
      Vendor: IBM Model: 2107900 Rev: 2700
      Type: Direct-Access ANSI SCSI revision: 05
./rescan-scsi-bus.sh: line 257: test: !=: unary operator expected
0 new or changed device(s) found.
0 remapped or resized device(s) found.
0 device(s) removed.

So, yes it throws some errors in between the output. But it is already fixed in later versions (no todo there) and isn't a functional issue.

IMHO thereby it is of low priority - which does not stop anyone from preparing and providing an upload, just that it likely will wait way back in the queue.