shwake@raysnec.UUCP (Ray Shwake) (06/04/90)
On at least two occasions, all the files in /usr/lib/uucp except uugetty and a local subdirectory were removed at 23:45 upon running uudemon.clean. Yet on other occasions it functioned correctly. This morning I found, again at 23:45 the sub-directories in /usr/spool/uucp/.Log were removed. Has anyone else experienced such occurrences??? Please email if you have any ideas.
kjk@PacBell.COM (Ken Keirnan) (06/06/90)
In article <45@raysnec.UUCP> shwake@raysnec.UUCP (Ray Shwake) writes: >On at least two occasions, all the files in /usr/lib/uucp except uugetty >and a local subdirectory were removed at 23:45 upon running uudemon.clean. >Yet on other occasions it functioned correctly. This morning I found, >again at 23:45 the sub-directories in /usr/spool/uucp/.Log were removed. > >Has anyone else experienced such occurrences??? Please email if you have >any ideas. Some versions of the HDB cleanup script(s) do a very bad thing. They assume all the files under /usr/spool/uucp are directory names. The "for" loop that does the cleanup looks something like: cd /usr/spool/uucp for i in * do cd $i . . cleanup code . . cd .. done Note that if one of the files in /usr/spool/uucp is not a directory (an ordinary file created by accident or by a locally developed program), the "cd $i" will fail leaving the program in /usr/spool/uucp and the "cd .." at the end of the loop will change directory to /usr/spool and the cleanup will continue from there. If this happens again, you are in /usr... you can figure out the rest. I strongly recommend if you have the above problem, to add a line at the top of the "for" loop to insure a directory is being processed: for i in * do if [ ! -d $i ]; then continue; fi cd $i . . Even better, also modify the "cd $i" to read "cd /usr/spool/uucp/$i" just to be sure. Hope this helps. Ken Keirnan Pacific Bell -- Ken Keirnan - Pacific Bell - {att,bellcore,sun,ames,pyramid}!pacbell!kjk San Ramon, California kjk@PacBell.COM
davidsen@sixhub.UUCP (Wm E. Davidsen Jr) (06/06/90)
In article <7585@pbhyf.PacBell.COM> kjk@PacBell.COM (Ken Keirnan) writes: This ugly shell script: | cd /usr/spool/uucp | | for i in * | do | cd $i | | . | . | cleanup code | . | . | | cd .. | done Any competent programmer would write cd $i || continue to insure that if the cd failed everything would fail cleanly. Yes, you can say [ -d $i ] || continue instead, or several other things, but the idea is that good programmers put error checking in their scripts, *and comments too!!* I don't find SCO any worse than anyone else on this, although they did still have "^" instead of "|" in some of the schell scripts which come with their text system. This makes them fail with ksh, and I reported it over a year before I bought my last text set. -- bill davidsen - davidsen@sixhub.uucp (uunet!crdgw1!sixhub!davidsen) sysop *IX BBS and Public Access UNIX moderator of comp.binaries.ibm.pc and 80386 mailing list "Stupidity, like virtue, is its own reward" -me
les@chinet.chi.il.us (Leslie Mikesell) (06/07/90)
In article <1095@sixhub.UUCP> davidsen@sixhub.UUCP (bill davidsen) writes: > This ugly shell script: > >| cd /usr/spool/uucp >| >| for i in * >| do >| cd $i >| . >| cleanup code >| . >| done > Any competent programmer would write > cd $i || continue >to insure that if the cd failed everything would fail cleanly. Perhaps any competent programmer that knew about ksh and its incompatibility with /bin/sh. I suspect that at the time that script was writtten, competent programmers knew that /bin/sh would exit if a cd fails (a wise default, in my judgement). >[...] but the idea is that good programmers >put error checking in their scripts, *and comments too!!* I don't find >SCO any worse than anyone else on this, although they did still have "^" >instead of "|" in some of the schell scripts which come with their text >system. This makes them fail with ksh, and I reported it over a year >before I bought my last text set. I'd put the blame on the authors of ksh for the incompatibilites, or whoever decided to use ksh to run scripts written for /bin/sh. Another annoying incompatibility is that "su -c user script" will execute user's .profile if user's login shell is ksh, but not with sh. This can cause surprising behaviour when the command is run by cron, the .profile has interactive commands, and the user changes his shell. Les Mikesell les@chinet.chi.il.us
det@hawkmoon.MN.ORG (Derek E. Terveer) (06/10/90)
In article <1990Jun7.155204.27108@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes: > Another annoying incompatibility is that "su -c user script" will > execute user's .profile if user's login shell is ksh, but not with sh. > This can cause surprising behaviour when the command is run by cron, > the .profile has interactive commands, and the user changes his shell. There is a test that one can put in the front of the .profile to inhibit reading the rest of .profile for batch environments. derek -- Derek Terveer det@hawkmoon.MN.ORG
davidsen@sixhub.UUCP (Wm E. Davidsen Jr) (06/10/90)
In article <1990Jun7.155204.27108@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes: | In article <1095@sixhub.UUCP> davidsen@sixhub.UUCP (bill davidsen) writes: [ ... ] | > Any competent programmer would write | > cd $i || continue | >to insure that if the cd failed everything would fail cleanly. | | Perhaps any competent programmer that knew about ksh and its | incompatibility with /bin/sh. I suspect that at the time that | script was writtten, competent programmers knew that /bin/sh would | exit if a cd fails (a wise default, in my judgement). You have a good point there. However, stopping is the last thing you want to do, since that would fail to do some of the cleanup. Perhaps a better solution (I've had time to think and your input) would be: [ -d $i ] && cd $i || continue since that works on sh and ksh, and does not stop if there is a file instead of directory present. | I'd put the blame on the authors of ksh for the incompatibilites, or | whoever decided to use ksh to run scripts written for /bin/sh. I can't argue with that, I think the ksh default is really dangerous, since something like cd foo; rm * Can kill you in ksh! | Another annoying incompatibility is that "su -c user script" will | execute user's .profile if user's login shell is ksh, but not with sh. ?? It will execute the profile names in the ENV variable, but I don't think it does .profile (unless ENV points there, of course). | This can cause surprising behaviour when the command is run by cron, | the .profile has interactive commands, and the user changes his shell. I'll look at this next week, but I think it's as I mentioned. I tried it VERY quickly, but I don't claim that I have the definitive answer. -- bill davidsen - davidsen@sixhub.uucp (uunet!crdgw1!sixhub!davidsen) sysop *IX BBS and Public Access UNIX moderator of comp.binaries.ibm.pc and 80386 mailing list "Stupidity, like virtue, is its own reward" -me