Error Trapping in ksh

[Ken Opersteny]

Greetings,

We have a 3rd party application to access our DB without our users having access to the unix prompt. We have run across a bug in their app that will allow shell access.

Is their a way to trap a bad CD call in a script or within a given ksh session?
The problem is something like:
cd directory
would return
user>ksh: directory: not found

due to the preceeding "/" being left off of "directory". (I do not have any control over the "/" being left off.)

Thanks,

Ken

[Bob E Campbell · Accepted solution]

Not sure I understand what you want to do in your override, but I could describe some generic rope and let you form your own noose :-)


Assume we have someone elses code *and* they use bare "cd"s:

$ cat cdcheck
echo "Trying to change to $1"
cd $1
echo "Done. Now in $(pwd)"

We can export an alias and function to take over the shell built-in:

$ alias -x cd=mycd
$ function mycd {
unalias cd
echo "Now in cd function"
if [[ ! -d $1 ]]
then
echo "Naughty directory"
else
cd $1
fi
}

$ typeset -xf mycd

$cdcheck /tmp
Trying to change to /tmp
Now in cd function
Done. Now in /tmp

[James R. Ferguson]

Hi Ken:

Good code assumes nothing and always tests for exceptions. In a shell script:

...
cd ${MYPATH} || { echo "Cannot 'cd' to ${MYPATH}"; exit 1; }
...

...for example, would cause a failure to 'cd' to exit the script with a return code of one after printing a descriptive message.

If you do not hava any control over the presence or absence of the leading '/' to make an absolute path, then you might write a shell-wrapper for the 3rd-party software that first performs a 'cd' into the path that the third-party application will complete.

For instance, if the 3rd-party application is called '/opt/DB/menu' then rename the application code (to, for example, '/opt/DB/menu.realcode') and craft a shell script (wrapper) that looks like:

#!/usr/bin/sh
MYPATH=/dbpath
cd ${MYPATH} || { echo "Cannot 'cd' to ${MYPATH}"; exit 1; }
/opt/DB/menu.realcode
exit $?

The above shell wrapper is named what the 3rd-party application is expected to be named. Thus, it runs providing the environment that you need.

Regards!

...JRF...

[Ken Opersteny]

Thanks for help!
Both of these suggestions are good. Since the code is embeded in an external application, there is no way to rename it or modify it, the shell wrapper would not work. (cool stuff though!)

James' tip is more along the lines of what I am looking for. However, when I try to change to a valid directory, I get an error and it doesn't work:
In cd function
In cd function
In cd function
In cd function
ksh: mycd: recursion too deep

If I change to a bad directory, it works correctly. If I remove the "cd $1" or substitute with an echo statement, it will return the echo. Sorry...I'm script challenged.

[TwoProc]

This making this change in *BOB's* script:
(I think you reversed in your posting your reference to James vs Bob's help, b/c you say James is more useful, but then you obviously are trying to run Bob's script).

echo "Naughty directory"
else
cd $1
fi
}

to refer to the binary for cd explicitly

echo "Naughty directory"
else
/usr/bin/cd $1
fi
}

that might work for you better.

[TwoProc]

Or another way to possibly handle it that *might* fix your problem.

...
echo "Naughty directory"
else
unalias cd
cd $1
fi
}
...

[OldSchool]

how are you launching the third party stuff today. simply executing a script in the user's .profile?

[Ken Opersteny]

Yes...had names mixed up. It is Bob's script that could work the best. The 3rd party app is a gui interface that can runs through the .profile and then into the GUI menu to access a Unidata database. Tried the other suggestions and still no joy.

Ok...figured it out. I do not exactly understand why, but this is what fixed it:
'cd' $1 (instead of cd $1)

Thanks for all of the help!

[Bob E Campbell]

The original script had an unalias and that worked for me. Hmmmm... Perhaps the problem is that the alias is expanded once and the alias is not reset unless the cd is eval/$()/``. I was running a ksh under my login POSIX shell... Have to add this one to my time-wasters list.

Glad it is working for you, but agree the best solution is to fix the program or invocation to avoid this. Clever is fun, but usually the wrong answer.

[Ken Opersteny]

Agreed Bob and I am working with the vendor to get the "bug" fixed!

[Dennis Handly]

>TwoProc: /usr/bin/cd $1

This won't work because it only changes the child process.

>unalias cd; cd $1

You don't need this over kill.

>Ken: but this is what fixed it: 'cd' $1

Naturally, as mentioned by the man page, that works or what I use in my mycd function:
\cd $1

QUOTING: The special meaning of keywords or aliases can be removed by quoting any character of the name.

[TwoProc]

Dennis,

Exactly where I wanted it unaliased. In the sub-process only. I didn't want it to undo the alias up higher in the call tree. Scope of the change was immediate only.

[Dennis Handly]

>TwoProc: Exactly where I wanted it unaliased. ... Scope of the change was immediate only.

You really want to narrow the scope to one word by quoting it. Who knows what the scope of unalias is. (You want to use the smallest hammer possible. :-)

[TwoProc]

Oh, I agree, and quoting it was a better idea (I didn't know about that one, and I'm glad I got to see how to handle this better).

But that's not what your comment was about, so I responded to your issue about the alias only changing the child process - which is exactly what I was shooting for when I made the suggestion.

[Dennis Handly]

>TwoProc: But that's not what your comment was about

I just said unalias was overkill.

>so I responded to your issue about the alias only changing the child process

No, my child process comment was about /usr/bin/cd being useless.