Reportedly, platform.uname gives UnicodeError for non-ASCII computer names on Windows, see http://www.pasteall.org/16215

I think it is incorrect that _node uses socket.gethostname on Windows. uname() should return the local hostname (i.e. the one that the system itself believes to have), independent of the network configuration or DNS.

Therefore, I think it should return the COMPUTERNAME environment variable, or the result of the GetComputerName() API.

Martin v. Löwis wrote:
> 
> New submission from Martin v. Löwis <martin@v.loewis.de>:
> 
> Reportedly, platform.uname gives UnicodeError for non-ASCII computer names on Windows, see http://www.pasteall.org/16215
> 
> I think it is incorrect that _node uses socket.gethostname on Windows. uname() should return the local hostname (i.e. the one that the system itself believes to have), independent of the network configuration or DNS.
> 
> Therefore, I think it should return the COMPUTERNAME environment variable, or the result of the GetComputerName() API.

There are two issues here:

1. socket.gethostname() shouldn't raise an error on Windows, but
   return the Unicode host name

2. COMPUTERNAME returns an uppercase version of the host name (which we
   could lowercase to stay b/w compatible), however I'm not sure
   whether this is the same as the socket.gethostname() or the
   NETBIOS name and I'm also not sure whether this is always set.

   This link suggests that it's using the NetBIOS name:
   http://www.scriptlogic.com/support/CustomScripts/environmentVariableReference.html

   The official Microsoft page is unclear about this:
   http://technet.microsoft.com/en-gb/library/bb490954.aspx

Could someone please check whether using the environment
variable COMPUTERNAME would work in the described case ?

What we could do is use the socket.gethostname() and fall back
to COMPUTERNAME in case of decoding problems.

Thanks,
-- 
Marc-Andre Lemburg
eGenix.com

________________________________________________________________________

::: Try our new mxODBC.Connect Python Database Interface for free ! ::::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               http://www.egenix.com/company/contact/

Marc-Andre Lemburg wrote:
> 2. COMPUTERNAME returns an uppercase version of the host name (which we
>    could lowercase to stay b/w compatible), however I'm not sure
>    whether this is the same as the socket.gethostname() or the
>    NETBIOS name and I'm also not sure whether this is always set.
> 
>    This link suggests that it's using the NetBIOS name:
>    http://www.scriptlogic.com/support/CustomScripts/environmentVariableReference.html
> 
>    The official Microsoft page is unclear about this:
>    http://technet.microsoft.com/en-gb/library/bb490954.aspx

More evidence that the NetBIOS name is used:

http://msdn.microsoft.com/en-us/library/aa368009(VS.85).aspx
http://msdn.microsoft.com/en-us/library/ms724295(v=VS.85).aspx

One problem with this approach is that changes to the NetBIOS name
are not seen by those APIs and variables, e.g. if the machine
get's an update via DHCP. The other is that NetBIOS itself is
being phased out in favor of DNS names - which socket.gethostname()
returns, so we'd be replacing a new technology with an old one.

http://blogs.technet.com/b/networking/archive/2008/12/16/netbios-browsing-and-windows-server-2008-x64-server-core.aspx

BTW: Why doesn't socket.gethostname() use GetComputerNameEx()
which does support Unicode ?

See http://msdn.microsoft.com/en-us/library/ms724301(v=VS.85).aspx

> There are two issues here:

There are two issues, but not here :-)

> 1. socket.gethostname() shouldn't raise an error on Windows, but
>    return the Unicode host name

This is issue 9377, please keep that out of this issue.

> Could someone please check whether using the environment
> variable COMPUTERNAME would work in the described case ?

No - I didn't personally encounter the problem.

> What we could do is use the socket.gethostname() and fall back
> to COMPUTERNAME in case of decoding problems.

I think using socket.gethostname() is conceptually wrong: the
what uname returns is *not* the name the machine has in DNS,
but what is configured in the kernel.

> More evidence that the NetBIOS name is used:
> 
> http://msdn.microsoft.com/en-us/library/aa368009(VS.85).aspx
> http://msdn.microsoft.com/en-us/library/ms724295(v=VS.85).aspx
> 
> One problem with this approach is that changes to the NetBIOS name
> are not seen by those APIs and variables, e.g. if the machine
> get's an update via DHCP. The other is that NetBIOS itself is
> being phased out in favor of DNS names - which socket.gethostname()
> returns, so we'd be replacing a new technology with an old one.

I think you misunderstand. It's not that this API returns the NetBIOS
name, but that NetBIOS really uses the same name that people understand
as their "computer name".

It's incorrect to use DNS names when implementing platform.uname():
on POSIX, uname() *also* does not return the DNS name. If you want
some API to return the DNS name of the computer, you need a different
function (e.g. socket.getfqdn()).

> BTW: Why doesn't socket.gethostname() use GetComputerNameEx()
> which does support Unicode ?

gethostname was specified by Berkeley Unix (4.2BSD specifically).
Microsoft can't just change the signature of the function.

If you are asking whether Python's socket.gethostname calls
gethostname: because this is the whole point of this function.
It would be very confusing if the function didn't call the
same-named platform API.

>It's incorrect to use DNS names when implementing platform.uname():
>on POSIX, uname() *also* does not return the DNS name. If you want
>some API to return the DNS name of the computer, you need a different
>function (e.g. socket.getfqdn()).

Even more importantly, the computer may have (and these days, usually has) more than one network interface and/or multiple IP addresses bound to a single interface.  Each IP address usually has a unique DNS name, but not necessarily.  In general, there can be no one-to-one mapping of platform name to DNS name.

Martin v. Löwis wrote:
> 
> Martin v. Löwis <martin@v.loewis.de> added the comment:
> 
>> More evidence that the NetBIOS name is used:
>>
>> http://msdn.microsoft.com/en-us/library/aa368009(VS.85).aspx
>> http://msdn.microsoft.com/en-us/library/ms724295(v=VS.85).aspx
>>
>> One problem with this approach is that changes to the NetBIOS name
>> are not seen by those APIs and variables, e.g. if the machine
>> get's an update via DHCP. The other is that NetBIOS itself is
>> being phased out in favor of DNS names - which socket.gethostname()
>> returns, so we'd be replacing a new technology with an old one.
> 
> I think you misunderstand. It's not that this API returns the NetBIOS
> name, but that NetBIOS really uses the same name that people understand
> as their "computer name".
> 
> It's incorrect to use DNS names when implementing platform.uname():
> on POSIX, uname() *also* does not return the DNS name. If you want
> some API to return the DNS name of the computer, you need a different
> function (e.g. socket.getfqdn()).

If think you are misunderstanding. The DNS name of a machine *is*
it's node name.

From the gethostname man page:

   Glibc Notes
       The  GNU  C library implements gethostname() as a library function that calls
       uname(2) and copies up to len bytes from the  returned  nodename  field  into
       name.

>> BTW: Why doesn't socket.gethostname() use GetComputerNameEx()
>> which does support Unicode ?
> 
> gethostname was specified by Berkeley Unix (4.2BSD specifically).
> Microsoft can't just change the signature of the function.
> 
> If you are asking whether Python's socket.gethostname calls
> gethostname: because this is the whole point of this function.
> It would be very confusing if the function didn't call the
> same-named platform API.

The MS API returns the DNS name as Unicode, so you don't into
those encoding in the first place.

I'll close this report as won't fix, since it's not platform.uname()
that needs to be fixed, but socket.gethostname() and that's issue
9377.

I'll copy the URLs to that issue.