done

A perfect example of why labels (sdb in this question) are dynamic and connected to no particular kernel major or minor number. @StephenKitt

So you do know: The labels that your answer show from the kernel are mere suggestions to UDEV. UDEV might choose to set any name it finds useful and only if there is no rule to change the kernel label is it used to name a device and create the directory entry. Any idea that a major and minor number defines a label is incomplete (to say the least).

Related: Read: superuser.com/a/686785.

What is dead is the static concept of device numbering, the system, not the use of major and minor numbers in the kernel (which actually provided such numbers when the device was detected).

drivers and devices are identified by majors/minors --> probably, as has been the custom for a long time. But that relation is not static nor constant. A scsi drive has a major of 8, doesn't it?. And an USB plugged disk also has a major of 8, does it?. And a disk inside a md (multi-disk) also has a major of 8, does it?. And an LVM virtual hard disk also has a major of 8, again?. How does the kernel apply the same driver (scsi) to completely different hardware elements? By being dynamic.

In the Debian documentation there is a clear description of which devices are still accessed by major/minor numbers: Kernel device drivers can register devices by name rather than major and minor numbers. (from: wiki.debian.org/DevFS)

@StephenKitt No, I am assuming nothing, and if anything has aggravated you I deeply apologize and assure you that was never (ever) my intention in any of my comments. Having said that: I also have the responsibility to point to errors where I find them. And the facts still remain true.

Let me reverse your previous comment into a question: The only name that a device of major 8 and minor 16 could have is /dev/sdb ? You seem to imply that there is an static relation between some numbers (major and minor) and the name, which isn't so. The relation is dynamic with udev.

Nowadays, the code that creates a name for a device is UDEV, isn't it?

This whole question is about naming, Isn't it?

Ah, found (again 20 years later) the reasons why the developer wanted to have an udev (before systemd apropiated it) and read (carefully): 2) udev does not care about the major/minor number schemes.

Yes, udev (if correctly used) has eliminated any limitation of naming (label) of kernel devices. Any reference to Major and Minor numbers is just used to preserve historical ideas. Please read landley.net/kdocs/ols/2003/ols2003-pages-249-257.pdf and the part: Part of the goal for the udev project is to provide a way for users to name devices based on a set of policies.. That is: a dynamic device naming system.

That, of course, is for the way that the scsi driver likes to name its partitions. GRUB might use another naming system (which is close to the one you report in your answer). And, of course, udev has changed all that old system.

I believe that the number 0 for a minor partition has been used for the whole disk in the (very old and now almost defunct Major and Minor numbering system that UDEV replaced). Read ibm.com/docs/en/ds8800?topic=host-linux-device-naming

@StephenKitt "Tell me what you brag about and I’ll tell you what you lack" – Spanish Proverb

@MichaelHomer Because that apply to you ? Or because you like to apply it to others to hide your own flaws ? Or else ?

Running ? Huh? youtube.com/watch?v=CpTyEX3a_a8

Any of them, but probably Voyager.

Favorite TV series?: Star Trek

The last couple of times we needed a mail migration all went fine for me. I don't see the problem. I just got the mail box in the car, drove to the new office, get the mail box in the new office, done. No problem.

[ "$(( 1 > 0 ))" = 1 ] && echo yes

Sorry, should also have the test:

@tripleee The command has a $ in front of the (( ... )). That is needed to work correctly in sh.

@JeffSchaller And, in the middle of that, there is perfect!

@StephenKitt Kiss my daughter, sniff a flower, get in awe when listening to Carl Orff's Carmina Burana. A pretty long list of things, Stephen.

A hash represents a set of key/value pairs:

From Perlintro: my %fruit_color = ("apple", "red", "banana", "yellow");

@FaheemMitha Yes, it is declared as a hash ....(array).

@FaheemMitha Could you point to the exact line that you do not understand?

I am not changing topic. You are failing to understand. Your "prove" has two different results, not the same value, so, it's a false prove, y is not storing the full fractional part, that is why you don't get the original value back. @StephenKitt

@user2357112supportsMonica So, a number that requires more than 53 bits gets rounded, right?. What about: awk -M 'BEGIN{ x=2^223; y=x+2; printf("%f\n%f\n",x,y) }', Why are neither x nor y rounded ? The number is using more than 200 bits, is it not? Repeat without the -M and see the difference. Explain it, please !!!

@StephenKitt I am saying that when the number has more than 53 bits the rest is removed (when it is a fractional number). For integers that doesn't happen with the -M option. But also happens for integers if the -M has not been used.

Why is 1152921503455511264.000000 being converted to 1152921503455511296.000000 (note that the end of the value is not 64 but 96).

which is wrong Prove it!!! @StephenKitt

That's an alternative interpretation, yes. But the numeric result is missing the numbers after the dot. Whichever was the reason to that to happen. @StephenKitt

@StephenKitt That variables don't contain full values only the integer part. In awk -M 'BEGIN { x=0xffffffffbb6002e0; y=x/1024; printf("%x\n%x\n", x,y*1024); }' awk removes the decimals (what is after the dot). Adding a -vPREC=200 makes awk correctly able to process more decimals. Better now?

@ilkkachu The one that likes arguing too much is you !

@ilkkachu Going somewhere? Ha, yes, I should .... :-)

@ilkkachu Exactly: You didn't see the distinction, but is your opinion the only one valid?

@ilkkachu We are not discussing how to replace a ; with something else. I am saying that a ; in basic parsing is not equivalent to a ; inside a if ...fi construct. Your examples just confirm that, by the way. But never mind, running in circles is never productive for anyone.

@StéphaneChazelas Cont (3) That is why (as basic parsing has not been suspended) not be a surprise that array=( ; a ; ; ; b ) doesn't work (as array=( a # ; ; b ) also doesn't). End (3).

@ilkkachu I am perfectly aware and clear that you are able to find a lot of corner cases to raise concern and deviate from the point raised. I won't go there. Bye.

@StéphaneChazelas Well, yes, there are other valid syntax(es) beside if cmd; then. I am well aware of them, as I hope you should be already aware. My point is somewhere else: .... The shell parser has a series of basic rules by which it splits a command line into words (tokens), One such rule is that a ; is a "word delimiter". We should agree up to this point. But there are some contexts that are processed by a different parser (well, technically, the same parser bound to a different set of rules). Cont. (1)

@StéphaneChazelas Cont (2) Like inside a pair of '', no ; or newline or other things are no longer special (and I used '' because it is pretty obvious what it does, but a similar argument could be built for ""). That different level of parsing also apply to the section between if and fi. That's why you can not have echo (true) while you can (perfectly valid) do if (true) then (echo true) fi (note that there are no ; and no newlines). So, the point is simply that the set of rules is different in basic parsing and in constructs like if (or while, case, for, etc.).

The ; in echo one; echo two is a control character. The ; in if list; then ... is part of the if syntax. They are different, not equivalent.

@Kusalananda Should this looong (side) discussion be moved to chat?