Permissions issue? 1

[mduddytel]

We have an issue that has come up with a particular login on our SCO Unix system.

There is a command in a script that appears to have stopped executing, or is failing

Here is the meat of the script - the command that appears to be failing is the "chmod" command.

/bin/unzip -P `cat /usr/local/lib/ptzip` *.zip
mv *.zip /v/fox/dmgt/received
ls > /usr/local/lib/ptoutfile
/usr/local/bin/upperlower
chmod 666 /v/fox/dmgt/received/*.out
mail -s "Paymentech response file retrieved and unzipped success

All of these commands execute, including sending the email. But the chmod command appears to have done nothing - the perms on the file are not altered.

After the script runs we can login as this user and run the chmod command and it works fine.

This issue just started happening, apparently out of the blue, on a day last week.

I am just barely out of newbie stage with admin issues in SCO Unix. Any help you can provide would be appreciated.

 

[SamBones]

First of all, if you put the commands you're listing in [ignore]

[/ignore] blocks, your code will display properly and be easier to understand.

Second, your commands don't look complete. I don't know what [tt]/usr/local/bin/upperlower[/tt] does, and the [tt]mail[/tt] line seems incomplete.

Finally, I don't see anything that creates a file with a '[tt].out[/tt]' extension.

Can you add an 'ls' before and after the [tt]chmod[/tt] to see what's going on?

Also, some versions of [tt]chmod[/tt] will take a '[tt]-v[/tt]' command line switch to be more verbose about what it's doing ('[tt]man chmod[/tt]').

...edit...

[b]ls -la /v/fox/dmgt/received/*.out[/b]
chmod -v 666 /v/fox/dmgt/received/*.out
[b]ls -la /v/fox/dmgt/received/*.out[/b]

...edit...

That will make it easier to see what is happening (or not happening).

 

[mduddytel]

My apologies for my shortcomings in the information provided.

Your comment:
Second, your commands don't look complete. I don't know what /usr/local/bin/upperlower does, and the mail line seems incomplete.
Response:
The "upperlower" command changes the name of the unzipped file to be in lower case. This is a requirement of the programming that will be accessing the file.

Your comment:
Finally, I don't see anything that creates a file with a '.out' extension.
Response:
The zip contains a file with an ".out" extension (the file comes from the "unzip" command in the first line posted).

Your comment:
Can you add an 'ls' before and after the chmod to see what's going on?
Response:
There is only one file in the folder - it is the file with the .out extension. How will adding an "ls" shed any light on this?

Your comment:
Also, some versions of chmod will take a '-v' command line switch to be more verbose about what it's doing ('man chmod').
Response:
There is nothing that displays on the screen when the script runs. I can add the verbose switch but am not sure how I will be able to see anything.
Sorry if this is grossly ignorant - I did say that I am a newbie.

 

[SamBones]

Nothing wrong with being a Newbie. Everyone was a Newbie at one time.

There is nothing that displays on the screen when the script runs. I can add the verbose switch but am not sure how I will be able to see anything.

The basic way to approach debugging is, get more information so you can figure out what's not working. Without more information, you're just guessing. You've really given us nothing to help debug with, so I suggested a few things that will make the script output some information that should help you figure out what's not working.

The '[tt]ls -l[/tt]' (the [tt]-l[/tt] part) will show the permissions on the file before and after the [tt]chmod[/tt]. That will show at that point, before and after, what the permissions are. That's hopefully to let you know if it worked. It doesn't matter that there's only one file, it will still let you see the details. You can't debug without details.

I realize there's nothing displaying. That's why I suggested adding the '[tt]-v[/tt]' switch, so it will display something. In most UNIX commands, if you add the Verbose switch, that will make it tell you what it's doing. Or not doing.

You're asking us to help you debug something with no information. I'm giving you ways of getting more information. The first thing you do when trying to debug something is get more information. Otherwise you're just guessing and that's a massive waste of time.

If you have these commands in a script, then you can do this do catch any output in a log file...

./myscript.sh > myscript.log 2>&1

# or

./myscript.sh 2>&1 | tee myscript.log

Then you can just '[tt]cat[/tt]' the log file to see what happened. BUT, you need to change the script so it outputs information.

Another thing you can do is add the command '[tt]umask 111[/tt]' to the front of the script. This will cause the '[tt].out[/tt]' file to be created with the permissions you want. Then you don't even need to use the '[tt]chmod[/tt]' command. It's also good practice to add comments and spacing to your script to make it easier to read and understand.

umask 111

# Unzip the file(s)
/bin/unzip -P `cat /usr/local/lib/ptzip` *.zip

# Move zip file to received directory
mv *.zip /v/fox/dmgt/received

ls > /usr/local/lib/ptoutfile

# Change file's case
/usr/local/bin/upperlower

# Show file details
ls -la /v/fox/dmgt/received/*.out

# Send mail notification
mail -s "Paymentech response file retrieved and unzipped success ... <missing end of command> ...

It's just good practice to make your scripts as chatty as possible and redirect the output to a log file. That way, whether it succeeds or fails, you have a record of what it did.

 

[mduddytel]

Thanks very much for the teach!
I will make the recommended changes and see what the results show.

 

[mduddytel]

Hello -
I have more information about the problem we are seeing.

I am also very hesitant to use the "umask" command since I do not want to change all file permissions for the login, just the permissions for the file created in this particular script. In addition, the requirement is to make a file read/write - there is no execute requirement. There are many other jobs that this login runs.

The purpose of the script that is running is to unzip a file to a specific folder on the server, then set the permissions on the unzipped file to be read/write, then send an email.
There is ALWAYS only ONE file unzipped.
The script is called from a different login using "rcmd".

Here is the command to call the script:

rcmd mysystem -l myuser /usr/local/bin/myscript "+myparameter+" > /dev/null 2>&1"

Here is the code for "myscript" (same as posted before:
Note that in this script "ptzip" is a job that retrieves the zip file
The "upperlower" script converts the file name to all lower characters

/bin/unzip -P `cat /usr/local/lib/ptzip` *.zip
mv *.zip /v/fox/dmgt/received
ls > /usr/local/lib/ptoutfile
/usr/local/bin/upperlower
chmod 666 /v/fox/dmgt/received/*.out
mail -s "Paymentech response file retrieved and unzipped success" myuser@mydomain.com < /usr/local/lib/ptoutfile

After the script runs there is only one unzipped file, as expected.
The unzipped file is present in the desired folder, the file name all lower case as required.
The unzipped file has no permissions at all.
We can log into the 'myuser' account and run the chmod command and it works perfectly. It is only when the script is called with "rcmd" that it does not work.

I'm not sure if this helps clarify the issue.
As stated previously this script worked without error for YEARS, then suddenly the "chmod" command stopped working in the script.

TIA for any help you can provide.

 

[SamBones]

Adding that '[tt]umask[/tt]' command to the script doesn't change it for the user, just for the running of that script. If you're worried, you can just set it back when your done. Like this...

# Save current umask value
PREVIOUS_UMASK=$(umask)
umask 111

# Do your script's commands here

# Set umask back to what it was
umask ${PREVIOUS_UMASK}

Whenever you run a script, your shell actually spawns a subprocess that it runs in, and the '[tt]umask[/tt]' command would change that child process's umask. So just within the script, not globally.

Even if you did manage to change the umask of the session you're logged into somehow, it would go away when you logged out and back in, unless you added it to your [tt].profile[/tt], [tt].bash_profile[/tt], [tt].bashrc[/tt], or whatever file sets up your session (depends on which shell you are using).

The way you are running the script (all output to [tt]/dev/null[/tt]) is basically throwing away any error messages it may be putting out. You are intentionally running blind. Try changing it like this...

rcmd mysystem -l myuser /usr/local/bin/myscript "+myparameter+" > [b]myscript.log[/b] 2>&1

Also...

The unzipped file has no permissions at all.

Uh, no. ALL files have permissions. Please provide the output of an '[tt]ls -l[/tt]' on the file. You can change the name, I just want the first part of the line that will look something like '[tt]-rw-rw-rw-[/tt]', or '[tt]-rwxrw-r--[/tt]', or '[tt]-r--------[/tt]', or even '[tt]----------[/tt]'. Those are the file's permissions.

Also, just to repeat, if you put an '[tt]ls -l[/tt]' both before and after the '[tt]chmod[/tt]' you can see if it worked or not. If you add a '[tt]-v[/tt]' command line switch to the '[tt]chmod[/tt]' it will tell you what it did or did not do. And you need to redirect the output of the command to a log file, not [tt]/dev/null[/tt], which is the trash can.

 

[mduddytel]

I will modify the script to direct output to the log file, and I will add the "ls -l" to the script so that's in the log.

Currently the output for the unzipped file with "ls -l" returns all dashes "---------------".
Is there an appropriate term for this permissions condition?

Thank you again for your help! I will report back with the log file info.

 

[SamBones]

That would be 'no access', but you're correct too saying 'no permissions'. It just seemed a little vague since you mentioned you were a newbie. Seeing the actual permission string helps.

Make sure to change your '[tt]chmod[/tt]' command to be this...

chmod [highlight #FCE94F][b]-v[/b][/highlight] 666 /v/fox/dmgt/received/*.out

That and capturing the output in a log file is the best you can do.

Or, forget the log file and just see it after you type the command...

rcmd mysystem -l myuser /usr/local/bin/myscript "+myparameter+"