topic Re: ksh program within backquotes won't work without having preceding "dot" (.) in Operating System - HP-UX

ksh program within backquotes won't work without having preceding "dot" (.)

B. Chapman — Tue, 24 Jul 2007 16:06:24 GMT

Experts,

I'm trying to help an Informatica PowerCenter (ETL tool) developer - and I'm out of ideas. Here's the scenario (3 files, all 777 perms until I resolve this):

ksh script -- /usr/local/bin/idpw -- has one line in it:

echo "MyID/MyPW"

ksh script -- /scripts/foo.WORKS -- has two lines in it:

idpw=`. /usr/local/bin/idpw`
echo $idpw

ksh script -- /scripts/foo.WONT_WORK -- has two lines in it:

idpw=`/usr/local/bin/idpw`
echo $idpw

BOTH SCRIPTS WORK FROM COMMAND-LINE (ksh).

But when the scripts are submitted thru Informatica tool, 2nd script returns NULL. All Informatica processes started with same ID/environment in which the commands work INTERACTIVELY.

What gives? Why is the "dot" REQUIRED for this to function? I wouldn't much care - except for the fact that we have a TON of legacy code that doesn't have the "dot" within the backquotes - and we'd rather not find and update all of those various scripts (even though, I know, find/sed would work for this).

Thanks in advance for any ideas/solutions!!!

Later,
Ben Chapman
bchapman@telcordia.com

Re: ksh program within backquotes won't work without having preceding "dot" (.)

Steven Schweda — Tue, 24 Jul 2007 16:19:01 GMT

> ksh script [...]

What makes it a "ksh script" if it doesn't
have something like:

#!/bin/ksh

as its first line?

Re: ksh program within backquotes won't work without having preceding "dot" (.)

A. Clay Stephenson — Tue, 24 Jul 2007 16:24:25 GMT

The first thing that I would do is to add a "shbang" line as the very first line of your scripts -- it was sloppy not to have one in the first place.

e.g.
#!/usr/bin/ksh

echo "Stupid Stuff"

Of course, this assumes this PowerCenter stuff observes the shbang convention.

Re: ksh program within backquotes won't work without having preceding "dot" (.)

B. Chapman — Tue, 24 Jul 2007 16:44:14 GMT

I'm sorry - it's kshell all the way. All 3 scripts have "#!/usr/bin/ksh" as first line, and, startup shell for all HP-UX accounts - most importantly - the Informatica account - is /usr/bin/ksh.

That was stupid of me not to mention that - I just wanted to simplify/shorten the scripts for the post.

Re: ksh program within backquotes won't work without having preceding "dot" (.)

B. Chapman — Tue, 24 Jul 2007 16:49:23 GMT

I guess I should also mention something else regarding informatica: These scripts have PRE and POST session scripts, and they have always executed with no problems in OUR CURRENT (and previous) Informatica versions. We have taken a copy of our production Informatica 7.x "system", put it on a sandbox, and upgraded to Informatica 8.x.

And this is where we're finding that the behavior is different - that is - backquoted script calls in shell scripts aren't being executed/interpreted/run/whatever.

We have opened a ticket with Informatica - and they (so far) have not been able to help out. Hence why I'm hitting up the gurus!

Re: ksh program within backquotes won't work without having preceding "dot" (.)

Patrick Wallek — Tue, 24 Jul 2007 17:00:37 GMT

Since the back-tick syntax is somewhat deprecated, try the $(..) syntax.

idpw=$(. /usr/local/bin/idpw)
echo $idpw

or

idpw=$(/usr/local/bin/idpw)
echo $idpw

Re: ksh program within backquotes won't work without having preceding "dot" (.)

B. Chapman — Tue, 24 Jul 2007 17:10:04 GMT

Patrick - thanks for the suggestion - but the idea is to get the pre-existing "legacy" code working without having to make any modifications.

And currently, all of our code has a BUNCH of lines with backquoted (tickquoted) programs:

#!/usr/bin/ksh
.
.
IdPw=`/usr/local/bin/get_id_pw.sh`
.
.

Which I know I can easily fix by using a dot (.), as in:

#!/usr/bin/ksh
.
.

IdPw=`. /usr/local/bin/get_id_pw.sh`
.
.

(or by using your more up-to-date convention)

#!/usr/bin/ksh
.
.
IdPw=$(/usr/local/bin/get_id_pw.sh)
.
.

But we're trying to avoid a massive code-update.

Re: ksh program within backquotes won't work without having preceding "dot" (.)

Sandman! — Tue, 24 Jul 2007 17:12:18 GMT

Try adding the eval builtin command to the "/usr/local/bin/idpw" script to force the shell to make another pass over it and execute it i.e.

#!/usr/bin/ksh

eval echo "MyID/MyPW"

Re: ksh program within backquotes won't work without having preceding "dot" (.)

A. Clay Stephenson — Tue, 24 Jul 2007 17:15:45 GMT

The only difference the dot should make is that the process is executed in the current shell rather than as a separate process. This also implies that a dot'ed command cannot contain an exit or return statement as that would immediately terminate the current process.

I would add "set -x" just after your shbang lines in the called and calling scripts and observe the output. Note that the set -x output goes to stderr rather than stdout.

I would also try running as the POSIX shell #!/usr/bin/sh to see if the behavior changes.

Re: ksh program within backquotes won't work without having preceding "dot" (.)

Steven Schweda — Tue, 24 Jul 2007 17:23:39 GMT

So, just to be clear, your script which "has
one line in it" actually has two lines in it,
and we really have no clear description of
what this "Informatica tool" really does with
the stuff you give it?

Knowing nothing, I'd say that you need to get
more info from the Informatica folks to find
out exactly what it does when you tell it to
do whatever you're telling it to do.
Particularly helpful might be knowing what
the new version does differently from the
older version(s). Trying to diagnose a
system which contains a black box along a
critical path sounds like a good task for a
talented psychic. (There may be one
following this thread, so you never know, but
my guess is that you'll need to find someone
who can peer into the black box.)

Re: ksh program within backquotes won't work without having preceding "dot" (.)

Dennis Handly — Wed, 25 Jul 2007 00:29:27 GMT

>Steven: Trying to diagnose a system which contains a black box along a critical path sounds like a good task for a talented psychic. (There may be one following this thread, but my guess is that you'll need to find someone who can peer into the black box.)

Psychics use quantum tunneling (tusc) to look into black boxes. ;-)

One difference about "." is that the file doesn't have to be executable. But Ben mentioned 777 permissions.

Re: ksh program within backquotes won't work without having preceding "dot" (.)

Peter Nikitka — Wed, 25 Jul 2007 01:46:38 GMT

Hi,

I'd like to wether your backtic script is really executed:
add something like this to /usr/local/bin/idpw:
print i am idpw >/tmp/logfile$$

and watch for the logfile.
Maybe the stderr is devnulled by the calling environment so error messages are invisible?

mfG Peter