Description of problem:
useradd/adduser does not allow the creation of users with capital letters.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
I would want to continue to create the customers with capital letters
Is there any reason that useradd changed this behavior between Red Hat Linux 8.0
and 9? As far as I can tell, this is not documented in the release notes, the
useradd man page, or even the --changelog for the shadow-utils package.
POSIX seems to allow user names to be mixed case:
It has been traditional in UNIX-like operating systems to allow uppercase
usernames as long as EVERY character isn't an uppercase. When every character
is an uppercase, the "login" program assumed you're using a terminal that
doesn't support lowercase and would convert all uppercase letters to lowercase.
But that leaves no reason why a username can't be mixed case.
This bug was noticed while using IBM Tivoli Identity Manager's (ITIM) Linux
Agent with RedHat 9. The default identity (aka username) generated has been a
users last name which includes capital characters. Noticed the change in
behaviour when moving the agent from RedHat8 (worked) to RedHat9 (failures).
Solaris 8 allows for mixed case user names and I would expect that linux would
too. (even if through some legacy flag being configured in /etc) I know that
mixed case userid's are in bad form but if a shop has mixed case unix id's and
want them to be the same across Unix's & Linux then Linux should allow for it.
As pointed out, POSIX doesn't claim lowercase only for user names.
Capital letters breaks sendmail (unable to deliver message: User unknown). On
classes on university all teachers told to us to not use capital letters in
login name because old Unixes thinks that terminal does not allow small capitals
if first letter of login name is capital. So you can write 'LS' and run 'ls'
even you are unable to write small capitals.
I was working with terminal like this (only capital letters) on university at 1991.
*** This bug has been marked as a duplicate of 89677 ***
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.