[13953] in Athena Bugs
sun4 7.7T: sunsoft wrapper perl script ...
daemon@ATHENA.MIT.EDU (Jake Wetzel)
Sat Oct 28 16:14:56 1995
To: bugs@MIT.EDU
Date: Sat, 28 Oct 1995 16:14:46 EDT
From: Jake Wetzel <jawetzel@MIT.EDU>
System name: spiderman
Type and version: SPARC/5 7.7T
Display type: cgthree
sunsoft dbx is symlinked to the wrapper perl script and it needs a little
work. Here's the script:
> #!/usr/athena/bin/perl
Perl seems like overkill in this situation. Couldn't a sh script be used
here?
> $LOCKER = "sunsoft";
> $LOCKERNAME = "sunsoft.new";
>
> if (! -d ("/mit/$MOUNTNAME")) {
> system("attach ${LOCKERNAME} > /dev/null");
> }
MOUNTNAME is undefined therefore this test is always true. Obviously it
should be $LOCKER. I think that the only program that uses wrapper is dbx
and since dbx is not on the normal sun path, wouldn't the mere fact that
wrapper is being run mean that the proper locker is attached? I doubt if
anyone would run dbx using the full afs path.
> $sunbase="/mit/sunsoft/sunwspro";
>
> $ENV{"LD_LIBRARY_PATH"} = "${sunbase}/lib:/usr/openwin/lib";
> $ENV{"LM_LICENSE_FILE"} = "${sunbase}/SunTech_License/license.dat";
> $ENV{"SUNPRO_SB_EX_FILE_NAME"} = "${sunbase}/SC3.0.1/lib/sun_source_brower.ex";
The LD_LIBRARY_PATH env variable is well documented and some users may have
set this env variable to other directories. I think you should append your
extra directories to this variable and not reset it.
> $pos = rindex ($0, "/") + 1;
> $prog = substr ($0, $pos);
>
> exec ("${sunbase}/bin/$prog", @ARGV) ||
> die "Can't run ${sunbase}/bin/$prog: $!\n";
It looks like wrapper is very general purpose. Since I believe only dbx
actually uses it, couldn't this be removed. If so, that would definitely
make the use of perl over sh overkill.
Jake Wetzel
