2

I have been struggling with this problem for a while. I have a script and within it, I have the following sed command:

DEF_CTLFILE1=$FDF_TOP/programs/sw_ctrl.ctl

sed "s/process_group_to_be_replaced_here/$PROCESS_GROUP/g" \
    ${DEF_CTLFILE1} > ${fname1}.ctl

When I allow a cron job to execute the script, the output (fname1.ctl) will be produced but have a size of 0.

Please note that I made sure that the two files contain aboslute paths within the variable definition (fname1).

When I manually execute the script, it works just fine. I suppose I need more understand on cron jobs and permissions and visibility but I am just starting out. Any and all tips would be much appreciated.

My version of Linux is Linux 2.6.18-348.6.1.0.1.el5 x86_64, Red Hat Linux 5.9 This is a ksh script.

Henk Langeveld
  • 8,088
  • 1
  • 43
  • 57
joshuafrostByte
  • 53
  • 6
  • 3
    It's an odds-on bet that your problem is the environment in which your cron-job runs. From your code, it is likely that `$FDF_TOP` is not set in the environment for cron; it is highly likely that it is set in your environment. If I'm right, there are a number of questions which this is a duplicate of (such as [Perl script works but not via cron](http://stackoverflow.com/questions/4341324/perl-script-works-but-not-via-cron/)). – Jonathan Leffler Mar 13 '14 at 22:10
  • Hello Jonathan, thank you for your reply. All of the variables in the script provide their absolute paths where applicable.In addition, I ensured that the path defined in the env in which my cron job runs has the path to the directory in which the ${DEF_CTLFILE1} resides. – joshuafrostByte Mar 13 '14 at 22:15
  • So your cron-run script includes `FDF_TOP=/some/absolute/path` as a line you didn't show? When a job is run by cron, it has almost no environment. If you want to see what environment, run `env > /tmp/cron.env.$$` as a command from a cron job. Examine the output. Now you know why you have problems. Unless you explicitly set `FDF_TOP`, it will not be set. – Jonathan Leffler Mar 13 '14 at 22:21
  • FDF_TOP gets set in the script: FDF_TOP=/$VAH/app/streamw VAH is an environment variable. So even if it was not set, why would it produce an output file but that file just be empty? Thank you very much for your engagement. I appreciate it. – joshuafrostByte Mar 13 '14 at 22:28
  • The empty file is probably created because (1) `$VAH` is not set, and (2) `/app/streamw/programs/sw_ctrl.ctl` doesn't exist, so (3) the `sed` command fails, but (4) the I/O redirection creating the empty file is done before the `sed` command fails. At least 95%, and probably nearer 99%, of the time when a 'command works when run from command line and not from `cron`', then the 'environment' is to blame. – Jonathan Leffler Mar 13 '14 at 23:43
  • It's possible that either: 1) the `cron` environment cannot find the `sed` executable (unlikely, but I've seen stranger things), or 2) `sed` is puking out some error to `stderr` and you're not seeing it because `>` is only redirecting `stdin` to your output file. Just as a sanity check, try appending a `2>&1` to the *end* of the line, and see if you get an error message in your output file. – Mike Holt Mar 14 '14 at 00:01
  • I did your suggestion Mike Holt and sure enough I get the following error within the file: sed: -e expression #1, char 41: unterminated `s' command I am doing some research on this but most the answers have to do with multi line replacement? I am not sure how that would pertain to my situation or why it would rear its' ugly head on a cron job verse command line. – joshuafrostByte Mar 14 '14 at 13:18
  • More suggestions: 1) Please provide valid examples of ALL variables in the script. 2) Add `set -u` to the top of the script to catch unset variables. This will also catch typos in variable names. 3) Run the script with `env - /path/to/script`. 4) Tell us if and how you've resolved this ;-) – Henk Langeveld Mar 20 '14 at 13:49
  • Check for your unix mail (cron sends mail with stdout/stderr) Start with a shebang line #!/bin/ksh Put debug statements in your script, such as set -x and echo ${DEF_CTLFILE1} And make sure you do not have a space after the \ – Walter A Mar 25 '14 at 17:09
  • Thanks for both of your responses. So prior to the sed command, the $PROCESS_GROUP actually is derived from an SQL call, sqlplus. This call was wrapped inside of a function. For some reason when it was wrapped inside a function and the cron job runs the script, the PROCESS_GROUP variable was getting corrupted. It would have two lines worth of data and therefore crapping out the sed command with the error sed: -e expression #1, char 41: unterminated `s'. I ended up refactoring this entire script (such as removing the SQL call from a function) and it ended up finally working. – joshuafrostByte Mar 25 '14 at 18:14
  • @joshuafrostByte I've copied your comment as a community answer. You might just copy the story in an answer of your own, and we can remove both the comments and that placeholder. – Henk Langeveld Apr 01 '14 at 21:43

2 Answers2

0

Placeholder for OP's own resolution to mark this as resolved.

Thanks for both of your responses. So prior to the sed command, the $PROCESS_GROUP actually is derived from an SQL call, sqlplus. This call was wrapped inside of a function.

For some reason when it was wrapped inside a function and the cron job runs the script, the PROCESS_GROUP variable was getting corrupted. It would have two lines worth of data and therefore crapping out the sed command with the error

sed: -e expression #1, char 41: unterminateds'`.

I ended up refactoring this entire script (such as removing the SQL call from a function) and it ended up finally working. – joshuafrostByte Mar 25 at 18:14

Community
  • 1
  • 1
Henk Langeveld
  • 8,088
  • 1
  • 43
  • 57
0

Thanks for both of your responses. So prior to the sed command, the $PROCESS_GROUP actually is derived from an SQL call, sqlplus. This call was wrapped inside of a function.

For some reason when it was wrapped inside a function and the cron job runs the script, the PROCESS_GROUP variable was getting corrupted. It would have two lines worth of data and therefore crapping out the sed command with the error

sed: -e expression #1, char 41: unterminateds'`.

I ended up refactoring this entire script (such as removing the SQL call from a function) and it ended up finally working

joshuafrostByte
  • 53
  • 6