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

[B. Chapman]

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

[Steven Schweda]

> ksh script [...]

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

#!/bin/ksh

as its first line?

[A. Clay Stephenson]

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.

[B. Chapman]

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.

[B. Chapman]

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!

[Patrick Wallek]

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

[B. Chapman]

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.

[Sandman!]

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"

[A. Clay Stephenson]

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.

[Steven Schweda]

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.)

[Dennis Handly]

>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.

[Peter Nikitka]

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