Linux script issue

[Cringer]

Having a bit of a brain fart. Can't work it out. Trying to get a script to move a bunch of tables to a new storage area. Annoyingly the KB only has the scripts for Windows which is less than useful!!

If I run the command from the command line, the table moves successfully, but if I run it from the .sh I get errors.

/usr/dlc11/bin/proutil /app/data/dbtemp/central -C tablemove advertbb SmallTables2

OpenEdge Release 11.7.17 as of Thu Feb 16 14:11:40 EST 2023

** Cannot find or open file /app/data/dbtemp/central.lk, errno = 2. (43)

If I don't qualify the database path I get

OpenEdge Release 11.7.17 as of Thu Feb 16 14:11:40 EST 2023

". (6956)does not contain area "SmallTables2

I run the shell script with the same user I run the commandline from.

Completely stumped to be honest.

RH8
OE 11.7.17

 

[Rob Fitzpatrick]

** Cannot find or open file /app/data/dbtemp/central.lk, errno = 2. (43)

Errno = 2 means the file does not exist. What do you see from ls -l /app/data/dbtemp/central*?

If I don't qualify the database path

If you don't qualify the database path then you have to be in the database directory. Are you?

". (6956)does not contain area "SmallTables2

That is very strange formatting for that error message. I'd expect it to look like Database does not contain area "SmallTables2". (6956).

Does the error look exactly like the text you posted, or is that strangeness a forum copy-paste issue?

When you look at your structure (e.g. querying _Area, or looking at central.st after running prostrct list), do you see an area with this name? Does it contain any objects?

 

[Rob Fitzpatrick]

Also, what does your .sh look like? It might help to see the shell script.

 

[Cringer]

Bloody typo. It's dbtmp.

 

[Rob Fitzpatrick]

It strikes me as a bit odd that you fully qualify the proutil path on the command line. That suggests that you don't already have DLC set and exported in your environment, and $DLC/bin in your PATH. I'm curious why that is. Are you working with multiple OE installations?

I ask because it impacts how you write scripts. If a new shell (e.g. the sub-shell in which a script runs) doesn't have the correct environment, you will have to define those environment variables explicitly, or source in a script that does.

 

[Cringer]

Thanks Rob.

 

[Rob Fitzpatrick]

Bloody typo. It's dbtmp.

Well, that would do it!

I was secretly hoping it would be something more interesting.

 

[Cringer]

It strikes me as a bit odd that you fully qualify the proutil path on the command line. That suggests that you don't already have DLC set and exported in your environment, and $DLC/bin in your PATH. I'm curious why that is. Are you working with multiple OE installations?

I ask because it impacts how you write scripts. If a new shell (e.g. the sub-shell in which a script runs) doesn't have the correct environment, you will have to define those environment variables explicitly, or source in a script that does.

We have a standard config that we import into scripts usually that sets DLC.

 

[Cringer]

Well, that would do it!

I was secretly hoping it would be something more interesting.

I found the slightly more interesting for you. The typo came about because I was trying to recover from the very weirdly formatted 6956 error. I got it working for that script but when I recreated the script to run for another database those weirdly formatted errors started appearing again.

I eventually worked out that because I had created the script from a Windows client (No compile license on the UAT system) all the line breaks had CR and LF and of course Linux doesn't like that. So I stripped the CR characters out with Notepad++ and it ran like a charm.

 

[Rob Fitzpatrick]

Okay, that is interesting!

For future reference, there is an easy way to find and convert text files with CRLF line endings in Linux:



xxd file: hex dump a file
file filespec: display the file type of one or more files
dos2unix filespec: convert line breaks in one or more files