On Thu, Jan 12, 2012 at 21:24, Tobias Burnus <bur...@net-b.de> wrote: > This patch changes the handling of the CHMOD intrinsic. > > Currently, libgfortran calls /bin/chmod via fork/exec. The problem is on one > hand that the re-implemented system() call is not 100% correct. > > On the other hand, it will not work on systems where /bin/chmod is not > available. For instance, RTEMS is such a system, which offers chmod() but > not /bin/chmod. > > > > The tricky part is that chmod() only supports an (octal) number for the > permissions. By contrast, the chmod utilility supports a much richer > symbolic syntax in addition. > > I have to admit that I had never expect a that complicated syntax, but the > patch also handles: > > umask 022; mkdir foo; my_chmod g+w-r,a+x,-w,o=u,u+s,+t foo > > > That's just a few lines of Fortran code (plus the attached patch for the > library): > > program my_chmod > integer :: stat > character(len=200) :: file, mode > if (COMMAND_ARGUMENT_COUNT() /=2 ) error stop "USAGE: my_chmod <file> > <mode>" > CALL GET_COMMAND_ARGUMENT(1,mode) > CALL GET_COMMAND_ARGUMENT(2,file) > call chmod(file, mode, stat) > if (stat /= 0) error stop "my_stat FAILED" > end program my_chmod > > Build and tested on x86-64-linux. > OK for the trunk? (4.7 or 4.8 ;-)
Nice! While this technically isn't a regression, I think it's safe enough for 4.7; some obscure modestring not working as expected is unlikely to be the end of the world, and it might take years for such issues to surface anyway. For such bugs, or for potential mode strings not supported by POSIX, an easy workaround is after all to call /bin/chmod with EXECUTE_COMMAND_LINE or SYSTEM. So, Ok for trunk. -- Janne Blomqvist
