Understanding tusc output

[VAS_1]

What would you make of this?

$ tusc sqr
tusc: sqr: Permission denied
exit(1) .......................... WIFEXITED(1)

$ which sqr
/software/psoft/hr891/bin/sqr/ORA/bin/sqr

$ tusc -o t.t `which sqr` # Suppress tusc output
SQR for PeopleSoft V8.46

SQR for PeopleSoft [program] ......

$ sqr
SQR for PeopleSoft V8.46

SQR for PeopleSoft [program] ....


Any ideas? What keeps tusc from executing that program directly?

Victoria

[wip]

Hi Victoria,

What is missing here is a proper understading the tusc utiliy.It is a utlity to trace the system calls invoked by processes.When you want to see the system calls invoked by a running process provide the pid as an argument to tusc,when you want to trace the system processes invoked by a progrem since its execution,you need to provide the command name as a argument along with tusc.When you specify a command as an argument to tusc it start the command and start tracing that command.

have a look at

http://hpux.cs.utah.edu/hppd/hpux/Sysadmin/tusc-7.8/man.html

[VAS_1]

wip wrote:

"When you specify a command as an argument to tusc it start the command and start tracing that command."

Right. I want to trace the system calls from the sqr program, so I started it with tusc. I want to understand what environment tusc is using, since it fails unless I call the command (sqr) very explicitly (`which sqr`).

[Andrew Merritt_2]

It might be something to do with what 'sqr' does with its standard output, since specifying a file for the tusc output (-o) allows tusc to run it.

Can't quite figure out exactly why this would happen, though.

Also, do you get the same behaviour with

$ tusc `which sqr`

?

Andrew

[VAS_1]

No, the -o 'file' flag isn't what makes it work, it's specifying the `which sqr` instead of just sqr.

I guess it's something to do with the pathing in the execve call in the tusc program:

execve("./sqr",...) ... ERR#13 EACCES

The above ./sqr is a directory. If I move it, then I get

execve("/software/psoft/hr891/bin/sqr",
[...] ERR#13 EACCES

And if I move THAT directory, then I get

tusc: sqr: No such file or directory

even though `which sqr` is valid.

Source code is unavailable for tusc so I can't see exactly what it is doing. I am kicking around writing a test program just to kick off an exec* call.

Victoria

[Andrew Merritt_2]

Are you sure it's tusc that's the problem, and not the shell? Which shell are you using? I'd have thought it is the shell which is erroneously passing the path to the directory 'sqr' into tusc, instead of the path to the executable. That behaviour is ringing a bell, but it's a very distant one, I'm afraid.

What does 'whence sqr' show? That uses the shell built-in, rather than the standalone program 'which'.

(And only 2 points when I suggested checking 'tusc `which sqr`'? :-) )

Andrew

[VAS_1]

I'm not sure it's tusc and not the shell, but if I change shells, I get the same behaviour.

'whence sqr' shows the same output as 'which sqr'

tusc seems to be parsing the PATH and trying to execute the first sqr it finds. If I mkdir sqr in some random directory that is pathed, I get the same behaviour:

execve("/opt/cobol/bin/sqr", ...) ERR#13 EACCES

>(And only 2 points when I suggested checking 'tusc `which sqr`'? :-) )

Yeah. I did that originally, I just included the one with -o t.t so I wouldn't have to say "output excluded" :-}

[VAS_1]

PS

# mkdir /opt/hparray/bin/mozilla

$ which mozilla
/opt/mozilla/mozilla
$ tusc -af -o t.t mozilla
tusc: mozilla: Permission denied

$ more t.t
[...]
execve("/opt/hparray/bin/mozilla"...) ERR#13 EACCES

[Andrew Merritt_2]

Hi,
I've had a quick play, and I see the same behaviour as you, if there is a directory of the same name as the executable ahead of the binary on the $PATH list, and the directory has the 'execute' bit set. So, basically, tusc is just going along the PATH list looking for a match for the name given that has the execute bit set, and not checking if it is a directory.

I'll ask the author if this is known or deliberate behaviour.

Andrew

[Andrew Merritt_2 · Accepted solution]

Victoria,
Yes, it is a bug in tusc, and you probably deserve a prize for spotting it; no-one has noticed this behaviour before. :-)

It will be fixed in the next release, which it is planned will come out around the same time as 11.31.

How serious is the problem for you?

Andrew

[VAS_1]

Andrew, you get your ten points now :) And the prize I want is a job in western North Carolina!

Since I know how to get around the problem and will share that knowledge with the folks here who might use the program, it's not an issue.

Might you ask the author if it is a call to an exec* function that causes the problem? I am facing a similar problem with another program (the truth comes out!), and it has got me befuddled. We could take this to email if that would be better.

I really really appreciate your tracking this down for me.

Victoria

[Chris Bertin]

If you are not providing a full path to tusc, it (like the shell) needs to find the executable. The logical call to use is execvp() but it is broken and it tries to execute directories in the path. So, any app using execvp() will have the same issue as tusc. A CR should be filed against execvp().

[VAS_1]

Chris! THANKS. Where can I find more information on the problem with execvp? I suspected it was causing a problem with another program, but I would like to read more on it.

Victoria

[Chris Bertin]

Sorry, Victoria, I have no idea where you could find more information. I just realized this problem existed yesterday. Most likely, it is not a widely known problem.

[VAS_1]

Thanks, Chris. Sigh. I seem to have a special talent for finding obscure problems.

[VAS_1]

execvp does seem not to function as I expected.