Yes, everything is complicated in its particulars. That's why it's fun to learn stuff.

tmp=$(sha512sum $sourcedir/$file | grep -v $not_this_file)

sha512sum $sourcedir/*.zz > part2.txt

Have you looked at what those "sha512sum" runs generate?

Yes, you may concatenate "shasum.txt" snippets. But you must be sure that the pathnames are the correct ones for when that "shasum.txt" is used.

Afaict, in your example (in the previous post) the pathnames in the file include "$sourcedir/" as path prefix, and therefore the checksum verification needs to be done with the files being in the "$sourcedir/" subdirectory of the current working directory.

If I may venture an opinion though, it generally makes the code less complicated and more easily reviewable when having a "shasum.txt" for all files in a directory be generated only once, when that directory is fully populated. Basically, your examples "like this, it works " are examples of good coding practice whereas the other examples "like this, it doesn't work" leave a bit in that respect. Which perhaps illustrates the point.

https://pkginfo.devuan.org/nvidia-legacy-340*

Yes, your technical advice is likely to be helpful.

But pretending to be an arrogant twit less so, although I can understand that there probably is a constructive basis for that artistic style in your mind.

I am thinking that Bookworm is a release of debian, and as such its developers would or should strive for backward compatibility in as many ways as possible with all of the possible uses of the debian software. I believe it serves the end user community quite badly to make up a "pseudo fight" about which particular software is the better one for some functionality. Especially when it concerns actually removing programs or packages that get deemed to be the lesser good, and certainly where it's widely used software.

I suppose if we keep needing to patch against debian developers' choices, then we end up at that place where debian is no longer our platform. Actually @Head_on_a_Stick, I believe you are well ahead of me there.

The nonsense keeps coming; I really should have closed this before.

@blackhole, that kind of post do very little to narrowing the gap in "street cred" between yourself and @MiyoLinux.

I think you too should train your own (new) forum appearance towards Professional, Precise and Polite.

What is this about?

I'm not aware of any "cooldown time between searches" here?

To get an association table between PCI address and device node name, I think I might do:

ralph@stolpe:~$ realpath /sys/class/block/sd?/ 
/sys/devices/pci0000:00/0000:00:1f.2/ata5/host4/target4:0:0/4:0:0:0/block/sda
/sys/devices/pci0000:00/0000:00:1f.2/ata6/host5/target5:0:0/5:0:0:0/block/sdb
/sys/devices/pci0000:00/0000:00:14.0/usb2/2-1/2-1.1/2-1.1:1.0/host6/target6:0:0/6:0:0:0/block/sdc
/sys/devices/pci0000:00/0000:00:14.0/usb2/2-1/2-1.4/2-1.4:1.0/host7/target7:0:0/7:0:0:0/block/sdd
/sys/devices/pci0000:00/0000:00:14.0/usb2/2-1/2-1.2/2-1.2:1.0/host8/target8:0:0/8:0:0:0/block/sde

My example case shows 2 SATA disks and 3 USB disks. You may note that sdd and sde got enumerated in "wrong" order by the scsi module (relative to the USB host/port enumeration) for some reason. This appears to be consistent for that setup, but on occasion sdc and sdd are swapped, which is something I deal with by repeated monkey handson (= unplug+plugin) until order returns.

As @rolfie noted, the reason those "reorderings" happen is probably because the kernel+module code is multi-threaded with separate threads handling separate devices independently and these threads then compete and synchronize about "acquire the next device node name" on a first-come, first-served basis.

The answer to why it turns up as a new thing for you would probably be that the kernel+module code involved has been updated to include a more refined multi-threading in one way or another. Or, it might be hardware related that something has changed with some parts of the hardware due to aging, causing the startup timings to be slightly different now compared to how they have been previously. I think we can agree to that magic is not involved.

I guess it would be kernel related since it's the kernel modules that invent the names.

Or, does the naming coincide with PCI numbering?
Eg that the PCI address for /dev/sda is lesser than the PCI address for /dev/sdb ?

If the git directory on your system has pathname /home/user/mygitworkspace you would remove that git directory with the terminal command sequence:

$ cd /home/user
$ rm -rf mygitworkspace

Technically, "rm" is the program to run, "-rf" asks for the command variation to delete stuff recursively and force deletion to apply also for read-only files/directories, and "mygitworkspace" identifies the top-level pathname of files and directories to remove.

@steve_v, that kind of opinionated aggression is totally uncalled for. You may consider this a warning.

Again, the desktop iso is installer (not refracta) + a package pool, and the pool1 iso is only a package pool.

The desktop package pool contains some complete desktop package collections and then topped up with 2500 "most wanted" popcon packages, whereas the pool1 package pool merely is the 5000 most wanted packages.

In both cases the choice collection is filtered against currently available packages (at building time), expanded to include the first-options Depends and Recommends, and also including first-option choices for any so called "pure virtual" packages.