0

I have a script which writes some header info to the screen using 3 echo commands, then is supposed to delete a file that was previously created (and does exist). The file is a 6-digit text file, named with the format ddmmyy.

#!/usr/bin/ksh
clear
echo "******************"
echo "Program name    Version: " $VERSION_NUM
echo "******************"

#Set the tmp directory
export MY_TMP_DIR="$MYPATH/$USER/tmp_$(date +%y%m%d%H%M%S)"

In a future script:

rm -rf $MY_TMP_DIR

These scripts are run by multiple users. 99% of the time it just deletes the temp directory, but in 1% of executions, it fails due to $MY_TMP_DIR being mal-formed.

After logging the command being evaluated. Turns out the value of the variable includes the 3 echo command outputs. Log file shows this is the string being evaluated (with line breaks):

"rm -rf /pathToWorkingAera/User1/tmp_******************
Program name    Version: 3.0.1
************
280220"

This causes mayhem (obviously) with the asterisks resulting in the deletion of all sorts of things. Luckily the system is access controlled to limit the damage.

The interim fix is to change the asterisks in the echo commands, to let the script fail safely and obviously the rm -rf is dangerous, but it's not the root cause of the error.

Can anyone suggest how the echo output might be getting picked up by the assignment of the "date" command output? How to prevent it? I can't fix it as I don't understand how come it's happening in the first place.

The issue is sporadic, not repeatable and not user-specific.

The system is RHEL7.7 bash. (Will try to provide any more details on request, if possible).

AlexC
  • 3
  • 2
  • 1
    That is `ksh` not `bash`; quote all the variables... – Jetchisel Mar 10 '20 at 11:37
  • Thanks, I corrected the tag to ksh. When you say quote all the variables, I don't follow. I assume you mean quotes around each variable, like …/tmp__"$(date +%y%m%d%H%M%S)" but that still doesn't explain why the issue is occurring <1% of the time. Or at all. Thanks. – AlexC Mar 10 '20 at 14:40
  • Quoting doesn't have to do with the problem, but might limit the damage, especially in the `rm` command (where an unquoted wildcard can delete many unexpected things). As for the actual problem, it looks a bit like the `date` command is somehow re-running the script itself; does someone have an alias or function that redefines the `date` command? What happens if you replace "`date`" with "`/bin/date`"? (Note that that's a workaround; you still should find out the source of trouble and fix it for real.) – Gordon Davisson Mar 10 '20 at 15:26
  • Thanks for the suggestions. Mitigations (quoting, asterisk removal) being implemented, but no root cause found yet. I'll update with any new information. – AlexC Mar 12 '20 at 11:02

0 Answers0