5 ms·

Talk to POSIX: > A string that is used to identify a user; see also User Database. To be portable across systems conforming to POSIX.1-2017, the value is compo

Talk to POSIX: > A string that is used to identify a user; see also User Database. To be portable across systems conforming to POSIX.1-2017, the value is composed of characters from the portable filename character set. The <hyphen-minus> character should not be used as the first character of a portable user name. * https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_437 https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1... The "portable filename character set" is defined as: A B C D E F G H I J K L M N O P Q R S T U V W X Y Z a b c d e f g h i j k l m n o p q r s t u v w x y z 0 1 2 3 4 5 6 7 8 9 . _ - * https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_282 https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1... So only a hyphen as the first character is forbidden. Given that you can't necessarilly control where usernames come from (e.g., LDAP lookups), properly speaking your system has to handle everything anyway, even if you don't allow local creation.

dfranke 2y ago
Yes, I'm aware, and POSIX has many such bugs that make command input or output unavoidably ambiguous if certain unexpected characters are present that they didn't think to prohibit. A lot of the revisions that went into POSIX 2024 were aimed at fixing some of these, such as standardizing find -print0 and xargs -0. The fact that this one got overlooked doesn't mean it's a good idea to make the situation worse and harder for future POSIX revisions to address.
bluGill 2y ago
It is time for POSIX to get with the times. Computers are used in more than the US and Canada (for the most generous interpretation of American in ASCII I'm including Canada, their French speakers will not be happy with that, not to mention first nations of which I know nothing but imagine their written language needs more than ASCII). UTF8 has been standard for decades now, just state that as of POSIX 2025 all of UTF8 is allowed in all string contexts unless there is a specific list of exception characters for that context (that is they never do a list of allowed characters). They probably need to standardize on utf8 normalization functions and when they must be used in string comparisons. Probably also need some requirement that and alternate utf8 character entry scheme exist on all keyboards. The above is a lot of work and will probably take more than a year to put into the standard, much less implement, but anything less is just user hostile. Sometimes commettiees need to lead from the front not just write down existing practice.
- chikere232 2y ago
  Sounds like lots of work and a lot of new bugs for no real value.
- throw0101a 2y ago
  > It is time for POSIX to get with the times. "Be the change that you wish to see in the world." — Mahatma Gandhi It's free to join: * https://www.opengroup.org/austin/lists.html https://www.opengroup.org/austin/lists.html * https://www.opengroup.org/austin/ https://www.opengroup.org/austin/
  - 7bit 2y ago
    [flagged]
    - throw0101a 2y ago
      > Most useless post so far Is GP willing to help out? To go through data structures and file formats (like pax[0][1] (née ustar (née tar))) to find places where things will need to be changed? It's easy to say "Someone else should fix things." [0] https://pubs.opengroup.org/onlinepubs/9699919799/utilities/pax.html#tag_20_92_13_01 https://pubs.opengroup.org/onlinepubs/9699919799/utilities/p... [1] https://pubs.opengroup.org/onlinepubs/9699919799/utilities/pax.html#tag_20_92_13_03 https://pubs.opengroup.org/onlinepubs/9699919799/utilities/p...
- atoav 2y ago
  Sure, go ahead. Write the PR and make sure to test against all other things used in production. Let's talk again in 30 years when you're done.
  - jerf 2y ago
    Oh, it's been closer to 20 years for the rest of the world to catch up to Unicode than 30. We aren't at "perfect" now but we're certainly down to the trickier corner cases that are difficult to even see how you solve the problems at all, let alone code the solutions, and that's just reality's ugly nose sticking in to our pristine world of numbers. But there really isn't any other solution. Yes, there will be an uncomfortable transition. Yes, it blows. But there isn't any other solution that is going to work other than deal with it and take the hits as they come. The software needs to be updated. The presumption that usernames are from some 7-bit ASCII subset is simply unreasonable. We'll be chasing bugs with these features for years. But that's not some sort of optional aspect that we can somehow work around. It's just what is coming down the pike. Better to grasp the nettle firmly [1] than shy away from it. At least this transition can learn a lot from previous transitions, e.g., I would mandate something like NFKC normalization applied at the operating system level on the way in for API calls: https://en.wikipedia.org/wiki/Unicode_equivalence https://en.wikipedia.org/wiki/Unicode_equivalence Unicode case folding decisions can also be made at that point. The point here not being these specific suggestions per se, but that previous efforts have already created a world where I can reference these problems and solutions with specific existing terminology and standards, rather than being the bleeding-edge code that is figuring this all out for the first time. [1]: https://www.phrases.org.uk/meanings/grasp-the-nettle.html https://www.phrases.org.uk/meanings/grasp-the-nettle.html
NoMoreNicksLeft 2y ago
> properly speaking your system has to handle everything anyway, even if you don't allow local creation. Honestly, I try not to be a pessimist, but this sounds like the opening narration to some dystopian doomsday movie. Titled something like You're Not Wrong, I suppose.

dfranke 2y ago

Yes, I'm aware, and POSIX has many such bugs that make command input or output unavoidably ambiguous if certain unexpected characters are present that they didn't think to prohibit. A lot of the revisions that went into POSIX 2024 were aimed at fixing some of these, such as standardizing find -print0 and xargs -0. The fact that this one got overlooked doesn't mean it's a good idea to make the situation worse and harder for future POSIX revisions to address.

bluGill 2y ago

It is time for POSIX to get with the times. Computers are used in more than the US and Canada (for the most generous interpretation of American in ASCII I'm including Canada, their French speakers will not be happy with that, not to mention first nations of which I know nothing but imagine their written language needs more than ASCII). UTF8 has been standard for decades now, just state that as of POSIX 2025 all of UTF8 is allowed in all string contexts unless there is a specific list of exception characters for that context (that is they never do a list of allowed characters). They probably need to standardize on utf8 normalization functions and when they must be used in string comparisons. Probably also need some requirement that and alternate utf8 character entry scheme exist on all keyboards. The above is a lot of work and will probably take more than a year to put into the standard, much less implement, but anything less is just user hostile. Sometimes commettiees need to lead from the front not just write down existing practice.

chikere232 2y ago
Sounds like lots of work and a lot of new bugs for no real value.
throw0101a 2y ago
> It is time for POSIX to get with the times. "Be the change that you wish to see in the world." — Mahatma Gandhi It's free to join: * https://www.opengroup.org/austin/lists.html https://www.opengroup.org/austin/lists.html * https://www.opengroup.org/austin/ https://www.opengroup.org/austin/
- 7bit 2y ago
  [flagged]
  - throw0101a 2y ago
    > Most useless post so far Is GP willing to help out? To go through data structures and file formats (like pax[0][1] (née ustar (née tar))) to find places where things will need to be changed? It's easy to say "Someone else should fix things." [0] https://pubs.opengroup.org/onlinepubs/9699919799/utilities/pax.html#tag_20_92_13_01 https://pubs.opengroup.org/onlinepubs/9699919799/utilities/p... [1] https://pubs.opengroup.org/onlinepubs/9699919799/utilities/pax.html#tag_20_92_13_03 https://pubs.opengroup.org/onlinepubs/9699919799/utilities/p...
atoav 2y ago
Sure, go ahead. Write the PR and make sure to test against all other things used in production. Let's talk again in 30 years when you're done.
- jerf 2y ago
  Oh, it's been closer to 20 years for the rest of the world to catch up to Unicode than 30. We aren't at "perfect" now but we're certainly down to the trickier corner cases that are difficult to even see how you solve the problems at all, let alone code the solutions, and that's just reality's ugly nose sticking in to our pristine world of numbers. But there really isn't any other solution. Yes, there will be an uncomfortable transition. Yes, it blows. But there isn't any other solution that is going to work other than deal with it and take the hits as they come. The software needs to be updated. The presumption that usernames are from some 7-bit ASCII subset is simply unreasonable. We'll be chasing bugs with these features for years. But that's not some sort of optional aspect that we can somehow work around. It's just what is coming down the pike. Better to grasp the nettle firmly [1] than shy away from it. At least this transition can learn a lot from previous transitions, e.g., I would mandate something like NFKC normalization applied at the operating system level on the way in for API calls: https://en.wikipedia.org/wiki/Unicode_equivalence https://en.wikipedia.org/wiki/Unicode_equivalence Unicode case folding decisions can also be made at that point. The point here not being these specific suggestions per se, but that previous efforts have already created a world where I can reference these problems and solutions with specific existing terminology and standards, rather than being the bleeding-edge code that is figuring this all out for the first time. [1]: https://www.phrases.org.uk/meanings/grasp-the-nettle.html https://www.phrases.org.uk/meanings/grasp-the-nettle.html

NoMoreNicksLeft 2y ago

> properly speaking your system has to handle everything anyway, even if you don't allow local creation. Honestly, I try not to be a pessimist, but this sounds like the opening narration to some dystopian doomsday movie. Titled something like You're Not Wrong, I suppose.