ttg@gryphon.COM (Ted Garrett) (02/03/90)
I noticed today that a function in my .kshrc is no longer functional. The basis of it is : if [ -w /etc/cron ] then ROOT=" root " else ROOT="" fi What this is supposed to do is set the variable ROOT to " root " if you are in Super User mode (basis is that if you are root, you can write to cron). In the new ksh (from the fixdisk), this no longer works as previously expected because cron's permissions and ownership are Permissions : 700 Owner : bin Group : bin So while this is a correction of a 'bug' in the ksh permissions checking, it's inconvenient in that I had to search out a file on my system which is actually owned by root and is read/write only by root. I used /etc/group. No biggie, but it may change the way some things get done on your system.
jcm@mtune.ATT.COM (John McMillan) (02/06/90)
In article <25508@gryphon.COM> ttg@gryphon.COM (Ted Garrett) writes: >I noticed today that a function in my .kshrc is no longer functional. The >basis of it is : > >if [ -w /etc/cron ] >then > ROOT=" root " >else > ROOT="" >fi : >So while this is a correction of a 'bug' in the ksh permissions checking, it's >inconvenient in that I had to search out a file on my system which is actually >owned by root and is read/write only by root. I used /etc/group. > >No biggie, but it may change the way some things get done on your system. What puzzles me, more than the permissions change, is why you're not doing something like: ROOT=" `expr \"\`id\`\" : '[^(]*(\([^)]*\))'`" if [ " root" != "$ROOT" ] ; then ROOT="" ; fi I may well be missing some point of your script, but it seems you're working overly hard to avoid the direct test. john mcmillan -- att!mtune!jcm -- juzz muttering for self, not THEM