Is \n in a windows domain user name interpretted as a line feed?

447
5
04-04-2019 12:50 PM
PaulHuffman
Occasional Contributor III

I had this happen when I was adding two new employees to my geodatabases with their OS logins from our Windows domain, using ArcCatalog 10.6.1 and the Administration> Add User workflow.  The first guy went easy,  the next guy didn't work. His domain login is ykfp/nrom***. The error message made us wonder if /n is getting read as a line feed and if I needed to escape this with quotes or something.  There must have been other places where someone had a domain name that included /n however, so it seems unlikely that I am the first to encounter this.   I also tried the other syntax for his domain name nrom***@KFO.local

Dropbox - AddingnromeroEd.png 

Yesterday, I successfully added ykfp\Nrom*** as a user to one geodatabase.  But my domain manager had given me ykfp\nrom*** as the login.  I haven't heard back from the domain manager when I asked him to check on the capitalization.  Does capitalization matter in Windows OS authentication?  I don't have a way to test this to see if it will work for the user.  I can't make an account on a PC in the domain as this user to try the geodatabase connection as ykfp\Nrom*** because I don't know the user's password.  Tomorrow, I plan to be in the user's office where I hope to work with him to install Desktop and add his geodatabase connections. 

Tags (1)
0 Kudos
5 Replies
DanPatterson_Retired
MVP Esteemed Contributor

In python, \n is interpreted as a newline

print("ykfp\nrom***")
ykfp
rom***

\N is worse in python

print("ykfp\Nrom***")
  File "<ipython-input-4-4938522fd86a>", line 1
    print("ykfp\Nrom***")
         ^
SyntaxError: (unicode error) 'unicodeescape' codec can't decode bytes in position 4-5: malformed \N character escape

This is because they lack raw encoding in python and in the world of Unicode, things are going to get worse.

The underscore _ is pretty well the only safe non-alphabetic/numeric acceptable character in many situations... don't know if it applies to your but an FYI at least

PaulHuffman
Occasional Contributor III

I was just working with Miguel at ESRI tech support who was amazed at this behavior on my server, and then was able to get the same kind of error using the Create Database User tool on his end with both Arc Catalog 10.5 and 10.6.1 when the user name started with n. 

Do you think there is a way to escape out of the \n combination in the domain user name when using ArcCatalog >Administration>Add User>Create Database User? 

I was able to use SSMS to add this ykfp\nrom*** login to my instance, geodatabases and roles,  but I was hoping that tomorrow I could demonstrate a simple workflow on how to add users and privileges using ArcDesktop tools to a fairly new employee that I want to take over as administrator for me soon. 

0 Kudos
DanPatterson_Retired
MVP Esteemed Contributor

No clue, but if \n fails, you might want to check for a few more trailing a slash

print("\nx\rx\tx\ax")
x       xx
There are loads... called escape characters
Which is why I don't like \ anything in the windows Unicode and/or python world
sometimes they throw useful error messages, leaving people a tad confused.  Your IT department should have a protocol setup I am sure
print("\nx\rx\tx\ax\xx")
  File "<ipython-input-2-fcf9ff201aa5>", line 1
    print("\nx\rx\tx\ax\xx")
         ^
SyntaxError: (unicode error) 'unicodeescape' codec can't decode bytes in position 12-13: truncated \xXX escape
0 Kudos
PaulHuffman
Occasional Contributor III

Yes,  this is a known bug.  https://support.esri.com/en/bugs/nimbus/TklNMDgyNjc2   It could turn up with other tools and Arcpy functions and also with /t.  Capitalize these if you can. Thanks to Miguel at ESRI Support.

0 Kudos
DanPatterson_Retired
MVP Esteemed Contributor

I wonder if they checked the others I listed as well... \a  \r 

plus all the others that will throw Unicode errors

0 Kudos