Please configure your mailer to send plain text emails instead of HTML email. Sending HTML email is causing your messages to be severely mangled. Save the HTML for web pages. Thanks. Here is a reference to your sent email so that you can see what we see.
http://lists.gnu.org/archive/html/bug-coreutils/2009-07/msg00090.html Benjamin Monjoie wrote: > [benja...@pal:~]$ type -a hostname > hostname is /usr/local/bin/hostname > hostname is /bin/hostname You have a local hostname in /usr/local/bin/hostname. It is overriding the system hostname (as it should) in /bin/. Your system did not provide /usr/local/bin/hostname. You must have installed it even if you don't remember doing it now. That is the root cause of your current issue. > [benja...@pal:~]$ hostname --version > hostname (GNU coreutils) 6.9 Yes. And it is operating correctly as designed and does not support the -f option. No bug there. > [benja...@pal:~]$ dpkg -l hostname > ii hostname 2.95 utility to set/show the host name or domain The system hostname. One of the other ones that isn't the coreutils hostname. That is the one that you have been expecting. It supports the -f option. It is still installed and operating correctly. Again no bug there. You are simply overriding it with a local copy in /usr/local/bin/ (as that override is supposed to work) and are seeing the GNU coreutils hostname behavior. > [benja...@pal:~]$ dpkg -L hostname | grep bin/hostname > /bin/hostname A little test I threw in so that if Ubuntu were doing something that I didn't now about I would learn where the command was located here. I don't have an Ubuntu system to test with at the moment. > I am expecting/hoping to see /bin/hostname is the _other_ hostname in > the system's hostname package and a /usr/local/bin/hostname that you > perhaps (?) just installed from a source compile of GNU Coreutils. And so it was! :-) > I don't think i've installed the other hostname. But you *did* install it. You installed /usr/local/bin/hostname from coreutils 6.9. Locally installed files are by convention installed in the /usr/local/ directory tree. Software distributions (such as the Ubuntu you are using and all other popular ones) do not install anything in /usr/local and leave that entirely up to the local administrator (you!) to do with as you see fit. If you have a hostname file there then it is because you have installed it. I think it much more likely that you simply did something recently and do not remember doing it rather than that a security breach occurred and that a malicious cracker broke into your machine to install GNU coreutils hostname in your /usr/local/bin/. :-) If you suspect that you have installed a package that installed files there then you can query the package manager for this. This will search the package database for any paths that match and will print out any packages with files there. dpkg -S /usr/local/bin This should not find any packages. If they do then those packages violate the system Policy document and you should report the bug to them. However, a purely local package is allowed to install files in /usr/local since by definitely it is a local administratory option. It is your directory. You can do whatever you want there. > It's probably my mistake but i don't see from where it came. > But I've tried the following : > [benja...@pal:~]$ sudo mv /usr/local/bin/hostname{,.bak} Yes, move or remove the file if you do not wish to use it. > [sudo] password for benjamin: Strange that you would need sudo for this. Does Ubuntu not support the 'staff' group like its parent Debian does? But that is a topic for another time on a different mailing list. > [benja...@pal:~]$ hostname -f > bash: /usr/local/bin/hostname: Aucun fichier ou dossier de ce type Unfortunatelly I cannot read that message but if it says what I think it says then it is telling you that your shell has hashed (saved, cached) the path that it previously found hostname at in /usr/local/bin/hostname and now it will never look for it again and so running hostname now _from that particular shell only_ has encountered an error because the cached location has disappeared. If you were to try this from a different shell that had not cached the path then it would have worked without problem. You needed to do 'hash -r' to tell the shell to rehash its table of saved command locations. hash -r For documentation see: help hash man bash You may want to set the bash option 'checkhash'. See the documentation for how it works. shopt -s checkhash > [benja...@pal:~]$ sudo ln -s /bin/hostname /usr/local/bin/hostname > ... > And it works. Although, it's not a very clean solution so if you have a > better one, i'm interested. Now that you have learned about the shell's command table hash you would be better served to remove your workaround. It isn't needed nor desired. If you don't remember installing things into /usr/local then perhaps it would be a good idea to review what is there and probably do some cleaning of it. Remember, the system doesn't put anything there (except some empty directories to provide the basic structure) so every file there is a file that you own completely. find /usr/local -type f -ls | less Bob _______________________________________________ Bug-coreutils mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-coreutils
