Need advice with a Unix script

[Arkitech]

This is probably a really simple problem, but goes easy on me I'm still a newb. The problem I have is that a script (we'll call it script.script) I edited won't run for some reason, I get the error that it's not found.

The location of my script is as follows: /home/users/arkitech

The actual script I'm running looks like this:

#!/bin/perl -w
#
##########################################################################
# NAME: script.script
# SYNOPSIS: script provides daily monitoring of system activity &
# disk usage
##########################################################################
# DECLARE VARIABLES
use strict;

companyservername:/home/users/arkitech-> whence sendmail /usr/sbin/sendmail

my @sar = qx(/bin/sar);
my @space = qx(/bin/df -k /dev/vx/dsk/elephant_fs/p1* | grep -v "Filesystem");
my $to = 'arkitech@att.com'; #
my $from = 'companyaddress@msg.ameritech.com';
my $date = scalar(localtime);
my $fs;
my $newfs;
my $kbytes;
my $used;
my $avail;
my $capacity;
my $mounted;

open(SENDMAIL, "|/usr/lib/sendmail -t ") or die ("Can't fork for sendmail daemon: $!\n");

print SENDMAIL "From: <",$from,">\n";
print SENDMAIL "To: ",$to,"\n";
print SENDMAIL "Subject: ODR daily capacity monitor\n";
print SENDMAIL "Reporting on ", $date, "\n\n";
print SENDMAIL "System Activity\n";
print SENDMAIL "-----------------\n";
print SENDMAIL @sar, "\n\n\n";
print SENDMAIL "Disk Usage\n";
print SENDMAIL "------------\n\n";
print SENDMAIL "Filesystem \t\tkbytes \tused \tAvailable\tcapacity\t Mounted on\n";
print SENDMAIL "------------------\t----------\t---------\t---------\t--------\t -------------------\n";

format SENDMAIL =
@<<<<<<<<<<<<<<<<< @<<<<<<<<<< @<<<<<<<<<< @<<<<<<<<<< @<<<<<<<<<< @<<<<<<<<<<<<<<<<<<
$newfs, $kbytes, $used, $avail, $capacity, $mounted
.

foreach (@space) {
chomp;
($fs, $kbytes, $used, $avail, $capacity, $mounted) = split(/\s+/, $_);
$newfs = substr($fs, 24);
write SENDMAIL;
}

print SENDMAIL "\n\nEnd of Report.\n\n";

close(SENDMAIL) or warn ("sendmail didn't close nicely! $!\n");

Thanks for any advice

 

[fishbits]

You including the path in the call to "script.script?"

 

[Arkitech]

yep, here's the statement that points to that location

companyservername:/home/users/arkitech-> whence sendmail /usr/sbin/sendmail

but even though I added that statement unix still does'nt see the script

 

[fishbits]

I see that within the script, I'm asking about the call to run the script itself. But could be missing something on my part.

 

[Arkitech]

Originally posted by: fishbits
I see that within the script, I'm asking about the call to run the script itself. But could be missing something on my part.

hmm not sure if I know what you mean. Basically all I've done is changed to the location of the script and attempted to run it. But for some reason the OS says it can't find it

 

[fishbits]

OK, this is what I've got: You have a script named "script.script" that will no longer run because the OS can't find it. Which would mean you're trying to run script.script. Which would mean that somewhere you are calling script.script to run, even if from the command line. In any case, where you are calling/running script.script, have you included the correct path?

 

[Arkitech]

Originally posted by: fishbits
OK, this is what I've got: You have a script named "script.script" that will no longer run because the OS can't find it. Which would mean you're trying to run script.script. Which would mean that somewhere you are calling script.script to run, even if from the command line. In any case, where you are calling/running script.script, have you included the correct path?

I'm pretty sure I'm calling it from the correct path. The script is located in my home directory which is home/users/arkitech, so I'm currently in that directory attempting to run the script but I still get that error. Hope that answers the question you're asking, I'm such a newb at this.

 

[Sunner]

Might be a silly question, but are you typing "./script.script" as opposed to just "script.script" ?
Assuming you're in the same directory as the script that is.

 

[Arkitech]

Originally posted by: Sunner
Might be a silly question, but are you typing "./script.script" as opposed to just "script.script" ?
Assuming you're in the same directory as the script that is.

ahh crap, I think that might be the problem

 

[fishbits]

ahh crap, I think that might be the problem

Yeah, that's why I was asking if you were including the path in the call. Hopefully that does the trick. That little thing takes a bit of getting used to, can drive you bats if its overlooked. Good deal if that fixes you up, but if not somehow the forum will get it sorted out.

 

[Arkitech]

Thanks for the help everyone, turns out I was trying to run the script just using the filename. Once I followed Sunner's advice I got it to run.


Thanks guys

 

[kamper]

Originally posted by: Arkitech
Thanks for the help everyone, turns out I was trying to run the script just using the filename. Once I followed Sunner's advice I got it to run.


Thanks guys

The proper solution is to add '.' to your PATH env var. For security reasons, make sure it's the last entry and it's usually not done for root (because it's still a little risky) but doesn't look like you're root.

 

[Nothinman]

The proper solution is to add '.' to your PATH env var.

No, the proper solution is just to get used to using the full or relative path when calling scripts that aren't already in $PATH.

 

[tranceport]

Originally posted by: Nothinman

The proper solution is to add '.' to your PATH env var.

No, the proper solution is just to get used to using the full or relative path when calling scripts that aren't already in $PATH.

 

[kamper]

Originally posted by: Nothinman

The proper solution is to add '.' to your PATH env var.

No, the proper solution is just to get used to using the full or relative path when calling scripts that aren't already in $PATH.

Sure that works, if you're really paranoid about making typos in directories that malicious people have access to. I mostly never change it as I type ./ impulsively by now anyway. Some of my machines have . by default, some not...

 

[Sunner]

Originally posted by: kamper

Originally posted by: Nothinman

The proper solution is to add '.' to your PATH env var.

No, the proper solution is just to get used to using the full or relative path when calling scripts that aren't already in $PATH.

Sure that works, if you're really paranoid about making typos in directories that malicious people have access to. I mostly never change it as I type ./ impulsively by now anyway. Some of my machines have . by default, some not...

Even if you put . last in your PATH, there are easy ways to trick you should one want to.
For example, something as simple as putting a program called "lsd"(very common typo, possible freudian slip?) in someone's home directory and have that program do something nasty.

Overall, it's just a bad idea, and a solution to a non existant problem.

 

[kamper]

Originally posted by: Sunner

Originally posted by: kamper

Originally posted by: Nothinman

The proper solution is to add '.' to your PATH env var.

No, the proper solution is just to get used to using the full or relative path when calling scripts that aren't already in $PATH.

Sure that works, if you're really paranoid about making typos in directories that malicious people have access to. I mostly never change it as I type ./ impulsively by now anyway. Some of my machines have . by default, some not...

Even if you put . last in your PATH, there are easy ways to trick you should one want to.
For example, something as simple as putting a program called "lsd"(very common typo, possible freudian slip?) in someone's home directory and have that program do something nasty.

Which begs the question either "why is your home directory world writeable?" or "why is root out to trick you?" /tmp is where you're more vulnerable.

Overall, it's just a bad idea, and a solution to a non existant problem.

Fair enough anyway, I retract the statement about 'proper' as, of course, not having it there is safer. It's never been enough of a concern to bother me.

 

[Sunner]

Originally posted by: kamper

Originally posted by: Sunner

Originally posted by: kamper

Originally posted by: Nothinman

The proper solution is to add '.' to your PATH env var.

No, the proper solution is just to get used to using the full or relative path when calling scripts that aren't already in $PATH.

Sure that works, if you're really paranoid about making typos in directories that malicious people have access to. I mostly never change it as I type ./ impulsively by now anyway. Some of my machines have . by default, some not...

Even if you put . last in your PATH, there are easy ways to trick you should one want to.
For example, something as simple as putting a program called "lsd"(very common typo, possible freudian slip?) in someone's home directory and have that program do something nasty.

Which begs the question either "why is your home directory world writeable?" or "why is root out to trick you?" /tmp is where you're more vulnerable.

Overall, it's just a bad idea, and a solution to a non existant problem.

Fair enough anyway, I retract the statement about 'proper' as, of course, not having it there is safer. It's never been enough of a concern to bother me.

It wasn't meant to be a likely real world example so much as just an example of something bad that could be done even with . sitting last in $PATH, but yeah, with /tmp you could get into trouble easily enough.

 

[Nothinman]

And chances are it won't be in your $PATH on any other unix box, so getting used to using ./ will make things easier if/when you have to use another box.