From: sens@FASECON.ECON.NYU.EDU (Sunando Sen) Subject: Re: Bug in fileutils-3.5, chmod +x doesn't work? getopt() update Date: Tue, 11 May 1993 02:05:55 GMT
In article <1skpmoINNrdq@ariel.ucs.unimelb.EDU.AU> duty@ariel.ucs.unimelb.EDU.AU (Duty Programmer) writes:
>
>In article <sens.101.736835991@FASECON.ECON.NYU.EDU> sens@FASECON.ECON.NYU.EDU (Sunando Sen) writes:
>>Hello all,
>>
>>I just tried out the GNU fileutils-3.5 and the command "chmod +x" doesn't
>>work. I always thought a command like "chmod +x *" is correct, but it gives
>>me only an error message ... Please forgive me, if the syntax is actually
>
>I was wondering when someone would post about this. You are right:
>there is a problem. It turns out that the problem is in the version of
>getopt() that's in the 4.3.3 libraries. The new fileutils requires a
>more recent version, so the options are:
>
> 1. Update getopt() in the C library (yuk)
>
> 2. Wait for hlu to release the new C library (presumably this
> will have the newer getopt() code. hlu ?)
>
> 3. Recompile chmod to use the newer getopt(). The code is actually
> in the lib subdirectory, but is bracketed by #ifdef __GNU_LIBRARY__
> so that it won't be compiled if you use the GNU libs. I'm not
> sure if using -U__GNU_LIBRARY_ is a good idea, so it might be
> safest if you just get rid of the ifdefs for now.
>
Thanks everyone, for the help. I took option 3 and it works. Of course,
the chmod binary now is a whopping 9k instead of 6k..., but chmod +x works
correctly now. I presume the problem is that the GNU fileutils no longer
accepts long options preceded by a "+", they have to be preceded by a "--".
But the getopt() in libc.a still does. Since "chmod +{rwx}" is the only
exception to this rule, it creates a problem. (It all becomes clear with
the benefit of hindsight).
Regards,
Sunando Sen