On Thursday 21 May 2009 08:45:05 Gabor HALASZ wrote:
> Cristian Ionescu-Idbohrn wrote:
> > On Thu, 21 May 2009, Gabor HALASZ wrote:
> >> Cristian Ionescu-Idbohrn wrote:
> >>> On Wed, 20 May 2009, Gabor HALASZ wrote:
> >>>> I have a little problem with chmod applet. The gnu verion of chmod
> >>>> command don't care about dead symlinks:
> >>>>
> >>>> ga-k8nf-9-1:~# ln -s nowhere /tmp/dead_link
> >>>> ga-k8nf-9-1:~# chmod +x /tmp/dead_link; echo ${?}
> >>>> 0
> >>>
> >>> Mine does:
> >>>
> >>> $ chmod -x dead_link
> >>> chmod: cannot operate on dangling symlink `dead_link'
> >>> zsh: exit 1 chmod -x dead_link
> >>
> >> Interesting :), but my problem is the return value of busybox's chmod -f
> >> +x.
> >
> > Hmm... What would you like it to do?
>
> The help of busybox's chmod said:
> lenny:~# chmod --help
> BusyBox v1.13.4 (2009-04-21 11:55:21 CEST) multi-call binary
> ...
> -f Hide errors
>
> I tried this option, and supressed the error messages, but the return
> value remains 1, instead of 0, so my scripts with set +e died. My
> question is simply: the nonzero return value is planned feature or bug?
> I think, in the first situation, the -f switch not required (2>/dev/null
> hide the error messages) in the applet, but I must will rewrite my
> scripts..
"hide" is not the same thing as "ignore". busybox behaves the same as latest
coreutils here, so it is correct.
simple way to handle this with set -e scripts is:
chmod ........ || :
-mike
_______________________________________________
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
