• We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.

problem with an sh script

ZippyDan

Platinum Member
I didn't make this script, but I am attempting to add to it. I have simplified it for purposes of posting here.

Basically, we use this very old linux-based (Cobol) accounting software in one of our branches. In the past, someone made a menu to access the different versions of the program which were used in different years. All the previous options work fine.

I have attempted to add a new "Option1" for the latest version of this old program.

When accessing the program through the menu, it launches and starts fine, and the user can enter the program, but when accessing certain parts of the interface, it seems to "crash" back to the menu. Honestly, I'm not sure if it is crashing or simply "losing focus" (this is more a Windows terminology since this is all CLI).

Alternatively, when the user access the same program (in this example APROGRAMFILE2) "directly" via a .bash_profile script, the program behaves normally as expected.

It may also help to know that the user is accessing the program via Putty using an SSH setting with the "Terminal-type string" set to "linux" instead of the default "xterm". The server is running CentOS 5.5.

Any ideas what could be causing this behavior with this relatively simple script? Is this some subtle difference between bash and shell?

I have pasted the sh script (which works to launch and run the program, but "crashes" consistently when accessing certain features) and the .bash_profile (which works fine in all cases) below:

menu.sh
Code:
clear;
menu()
{
clear;
echo "     1. Option 1"
echo "     2. Option 2"
echo "     Exit: (X/x)"
echo -e "Enter your option................: \c";read option
}

option1()
#note I have tried 'sh APROGRAMFILE2´and 'sh ./APROGRAMFILE2' here just to be thorough
{
cd /some/directory2
sh APROGRAMFILE2
menu;
}

option2()
{
cd /some/directory1
sh APROGRAMFILE1
menu;
}

menu
while :
  do
    case $option in
        1)  option1;;
        2)  option2;;
        x)  exit;;
        X)  exit;;
        *)  menu;;
    esac
  done
clear
echo "Finish"
clear;exit

.bash_profile
Code:
if [ -f ~/.bashrc ]; then
. ~/.bashrc
fi

PATH=$PATH:$HOME/bin

export PATH
cd /some/directory2
./APROGRAMFILE2
 
Last edited:
Why "sh ./foo" and not "./foo" like in the other script?

Is the change of cwd necessary? If not, then "/some/directory2/APROGRAMFILE2" would save one line.
 
Why "sh ./foo" and not "./foo" like in the other script?

Is the change of cwd necessary? If not, then "/some/directory2/APROGRAMFILE2" would save one line.
That's what I was thinking too, but with "/some/directory2/APROGRAMFILE2 --whatever-option=configdir"

You really need to figure out if the new version is crashing though, as monkeying around with the script is a waste of time if it is.
 
Why "sh ./foo" and not "./foo" like in the other script?

Is the change of cwd necessary? If not, then "/some/directory2/APROGRAMFILE2" would save one line.

As I recall, without the 'sh' it wouldn't run. I was just building off an existing script, and the 'sh' was there for the older versions of the program, so I used it.

I think I'm just going to rewrite the script from scratch in bash and see what happens.
 
rewrote the script in bash, still had a similar problem, though this time i was getting an error code in the program pointing to a specific data file instead of just a crash back to the menu

using the error code and some tech support, was able to narrow it down to a permissions problem.
 
Back
Top