Re: bug in hostname

[Jim Meyering]

Martin MOKREJŠ <address@hidden> wrote:
>   I never got final emails from developers regarding a fix to this problem.

IMHO, this isn't a big problem.
But if someone provides a patch to make coreutils' hostname support
more options, along with appropriate documentation, that'd be great.

Do any of you know if there is a `hostname' program that is featureful
and portable enough that we could simply remove hostname from coreutils --
or at least stop installing it?  For one thing, I've just noticed that
the net-tools hostname (version 2.13) has a minor problem in that it
doesn't detect a write failure:

    $ /bin/hostname > /dev/full
    $ /bin/hostname -V
    hostname 2.13

The hostname from coreutils does this:

    $ hostname > /dev/full
    hostname: write error: No space left on device
    [Exit 1]

> There were mentioned other tools being buggy

`buggy'?  Please be precise.  Which tools.
If a bug has been reported and it hasn't yet been dealt with,
then please post again.

> or behave in a different
> way(i.e. conform POSIX) like tail(1), head(1) etc.

Yes, the newer versions of head, tail, sort, uniq, etc. conform to
POSIX 200112 on certain systems, and people have complained that their
scripts malfunction as a result.  The problem is that the standard
changed how options like +N must be treated.  With the previous
version of POSIX, +N was an option.  Now, it must be treated as a
file argument, so it no longer makes sense to accept `sort -1' but
not `sort +2'.  Likewise with tail.  And by analogy, with head, etc. too.

The work-around is to set _POSIX2_VERSION=199209 in the environment.
Then the affected tools work according to the older standard.

> Please refresh
> http://www.mail-archive.com/address@hidden/msg00779.html thread and
> possibly built into a configure check that no
> filutils/textutils/sh-utils/net-tools are installed if they are known to
> install files into same location.

IMHO, this is not a job for `upstream' package maintainers, but
rather for distribution package maintainers -- and for those who
take it upon themselves to build/install their own binaries.

> Please, save us headaches. I hit the same
> problem now on Gentoo, and as I browse Gentoo's bugzilla, I was not the
> only one. :(