Re: PATCH: Bugs in brp-compress and brp-sparc64-linux

[Andreas Gruenbacher <ag bestbits at>]

On Sun, 24 Mar 2002, Tim Mooney wrote:

> In regard to: PATCH: Bugs in brp-compress and brp-sparc64-linux, Andreas...:
>
> >Hello,
> >
> >The brp-compress and brp-sparc64-linux scripts contain a bug, described
> >below, that results in broken symlinks with recent versions of fileutils.
> >
> >Both brp-compress and brp-sparc64-linux use the following commands to read
> >the target of a symbolic link, which is not a very good idea:
> >
> >    ls -l | awk '{ print $11 }'
> >
> >This no longer works with recent versions of ls, starting with
> >fileutils-4.1.5 or earlier. The reason is that the `ls -l' format has
> >apparently changed:
> >
> >    old:  -rw-r--r--    1 ag       users           0 Mar 23 21:31 l -> f
> >    new:  -rw-r--r--    1 ag       users           0 03-23 21:31 l -> f
>
> Are you sure this isn't something related to locale?  Are you using the
> C or POSIX locale, or some other?

Oops, my LANG variable was indeed set to en_US for some reason.

The proposed alternative commands `ls -l | sed -e 's/.* -> //'' are still
more robust as they don't depend on the locale.

> I haven't looked at brp-compress or any of the other brp scripts, but
> my guess is that if there's a bug, it's probably that the scripts are
> assuming C/POSIX locale when they should be forcing the locale by setting
> it themselves (LANG=C; export LANG).
>
> The only reason I say that is because the find-provides/find-requires
> scripts that I have contributed for various OSes had the same bug, until
> Marc Stephenson from IBM pointed out that the scripts assumed C/POSIX.

Yes, this seems to be the case.

--Andreas.