[PATCH] do not use gethostbyname() for hostname -s

[Michael Tokarev]

10.12.2013 01:40, Tito wrote:
> On Monday 09 December 2013 18:56:43 Michael Tokarev wrote:
>> There's no reason to call gethostbyname() on the value returned
>> by uname() when asked just for a short name of a host.  This may
>> also be wrong, when uname is set to one value, but in /etc/hosts
>> (or elsewhere) the "canonical" name is different.  This is often
>> the case for localhost entry in /etc/hosts:
>>
>>   127.0.0.1	localhost	myname
>>
>> With this content of /etc/hosts, and uname being set to myname,
>> busybox hostname -s will return localhost, while regular
>> hostname utility returns myname.
>>
>> Fix this by not calling gethostbyname() for the simple `hostname -s'
>> use.
[]
> Hi,
> I cannot reproduce the case you show with busybox hostname
> and /etc/hosts on debian 7:

Interesting.  Debian7 is exactly the system where I had issues with
original implementation:

 $ uname -n
 gandalf
 $ head -n1 /etc/hosts
 127.0.0.1	localhost gandalf
 $ hostname -s
 gandalf
 $ busybox hostname -s
 localhost
 $ cat /etc/debian_version
 7.2
 $ _

_My_ /etc/hosts actually has the first line like this:

 # list real hostname first localhost second or else busybox return wrong name
 127.0.0.1	gandalf localhost

and it is dated Sep-2010, so the comment should be from 2010 or before.
I changed it like shown above for this test.

Today I discovered the same issue within a freshly installed debian system
in a virtual machine, the generated /etc/hosts had similar line

   127.0.0.1 localhost debian

which resulted in busybox testsuite to fail (hostname-s-works failure due to
busybox returning localhost while system hostname returns debian).  This
failure prompted me to try to fix this finally.

The thing is that busybox hostname calls gethostbyname() on the
result of uname() call, while system hostname doesn't do this.  But the patch
shows it too.

> Even modifying /etc/hosts makes no difference:


> So now I'm wondering where "(or elsewhere)" could be?

Well, I don't know what's wrong with our systems.. ;)


> BTW.: It is better if you attach patches as my or your email client
> ate the tabs and the patch doesn't apply cleanly.

Almost always when someone sends patches as attachments, people
complain saying it is better to send patches inline.  It really
is easier to reply to inline-patches adding comments to particular
place in the patch, and here I agree too - it is better to send
patches inline.

My client can't ate tabs, -- it is more, I see the tabs in your
reply exactly as they were in my initial email.  I used
/usr/sbin/sendmail directly to send my initial email ;)

I just tried saving the patch (whole my email) from thunderbird
to a temp file and applying it - it applies cleanly to both
1.21 version and current git head.  Patch utility strips CRs
when applying, but that's typical.

Thanks,

/mjt