If you use:
sudo scutil --set HostName name-you-want
it will work a bit better. From the scutil(8) man page:
Retrieves the specified preference. The current value will be
reported on standard output.
Supported preferences include:
ComputerName The user-friendly name for the system.
LocalHostName The local (...
After following Jeffrey J. Hoover's tip,
sudo scutil --set ComputerName "newname"
sudo scutil --set LocalHostName "newname"
sudo scutil --set HostName "newname"
I would add these last two steps.
Flush the DNS cache by typing:
Restart your Mac.
EDIT: It didn't work for me until I restarted my mac.
Had the same problem. I deleted one of my project's folder and it became broken.
In this case the site's configs should be removed from httpd-vhosts.conf and httpd.conf.
Try ping 127.0.0.1
apachectl configtest can help you to detect the problem.
You can define what you want to see before the $ in your terminal by modifying the file ~/.profile.
For example if you add to the file ~/.profile the following line:
# h is the host name, w the complete path
export PS1="\h:\w$ "
you will see the host name and the complete path of the current directory:
You can also ...
Assuming the Firewall is turned off, then in order to ping $HOSTNAME, there has to be some form of sharing or service enabled in System Preferences > Sharing, or add an entry to the /etc/hosts file, depending on how/what you're trying to access by $HOSTNAME. Example, 127.0.0.1 computer_name where computer_name is what's reported by echo $HOSTNAME or in lieu ...
Check your hosts file, because probably it's malformed. It should look similar to this one:
# Host Database
# localhost is used to configure the loopback interface
# when the system is booting. Do not change this entry.
Open TextEdit as sudo
sudo -b /Applications/TextEdit.app/Contents/MacOS/TextEdit
Open /etc/hosts in this new TextEdit instance using any of the following methods:
Append the path to the end of the previous command
Use File → Open
Drag the file to the sudo'd TextEdit on the Dock
Alternatively, you can edit in Terminal using nano:
SUDO_EDITOR=nano sudo -e ...
Create a new Inbound Rule that allows traffic over UDP port 5353 in the needed security zones.
Open Windows Firewall Advanced Settings
Create a new rule in Inbound Rules
Under Protocols and Rules, choose Protocol Type > UDP and Specific Ports > 5353
Choose the appropriate security zones for your network. For more information on security ...
Everything seems to be working now. I can access localhost again, and my app is running Sinatra on Thin as it was before. Thanks to bmike, I did a bit of searching on why my loopback was unreachable and came across this article. I moved my old hosts file (/etc/hosts) to hosts.old and made a new one in its place that simply contained:
# Host Database
Protecting with ‘schg’, the system immutable flag, is a potential solution, depending on how much protection you need. You can set the schg flag using
sudo chflags schg /etc/hosts
Removal of the protection depends on your kernel security level. Run sysctl kern.securelevel:
1 means you need to boot to single-user mode to run chflags noschg /etc/hosts,
The hosts(5) manual page provides some insight into how /etc/hosts is used.
The file is used by mDNSResponder and, given your question, I suspect you want to see edits to /etc/hosts reflected in your DNS look-ups.
After each edit of /etc/hosts reset the mDNSResponder cache using this Apple technical note, OS X: How to reset the DNS cache:
The Cisco AnyConnect VPN Client is known to show this behavior. It will reset your /etc/hosts file on reboot to the contents of /etc/hosts.ac.
If you use this VPN client, you should make your modifications to both files.
See this hint for more info.
unfortunately the answer is no. Here's another answer to a very similar question. It's not the same question, but the answer is the same:
As a side note, you might be interested in this blog post. It won't solve your problem, but is quite interesting nonetheless (the domain name for this address, and the blog title ...
I have no such problems connecting to a web server when it's actually listening on port 80.
If you have no web server running, here is what you should get from terminal to show that name resolution is working on all network interfaces before the telnet gives up connecting to port 80:
mac:~ me$ telnet localhost 80
telnet: connect to address ::...
You could try TextWrangler for this sort of thing; much more capable than TextEdit, and if you use the direct install from BareBones Software instead of the App Store version, it will happily open locked files. When you try, it asks permission, reminding you that you are not a member of the required group, but password entry will allow you to open and edit ...
The problem could be that the hosts file might have been corrupted from the original ASCII encoding. I cleared all spaces and put tabs in it, ran sudo killall -HUP mDNSResponder (you can do that instead of rebooting) and after, it worked.
Usually only the root user is allowed to modify the file hosts.
To do that and fix your hosts file or your /etc folder (depending where you applied your read/write permissions) follow these steps:
Throw away your newly created hosts file (but not the old one!)
Repair your permissions with Disk Utility.
Open Terminal and enter sudo nano /etc/hosts and hit ↵...
You're not actually mapping ::1 to 127.0.0.1 in this case. You're providing an invalid name for ::1 that is essentially disabling the entry. You can't map an ipv6 address to an ipv4 address - they're not compatible.
If you need localhost resolution for ipv6 to not be enabled, simply comment the ::1 line out, or don't include it at all.
The man page that you referenced is very old (ancient) - it's from 1995. Looking at the man page for gethostbyname on a machine running El Capitan (2006), that reference is no longer there meaning it's a very good indication that what you are looking for has been deprecated.
As stated, it's pretty difficult to do this. However, if you're willing to change the goal a little, and use a name ending in ".local" instead of ".com", it's trivial (in fact, it's already being done for you).
Let me start with a little networking theory. I think you're mixing up two different levels: name resolution and routing.
Name resolution is how ...