osync
osync copied to clipboard
deajan
bash error on execution of osync.sh
Describe the bug Execution of osync.sh from the master branch exits with error on line 2347.
To Reproduce Steps to reproduce the behavior:
- Run osync.sh from master branch
Expected behavior Process should print help without error
** Deviated behavior** Error : /usr/local/bin/osync.sh: line 2347: [: ==: unary operator expected prints
To be honest that's a bit empty as a bug report.
I just reviewed line 2347, and the variable that gets compared there gets initialized no matter what, so I don't really see the problem here.
Would you mind giving some more info please ?
Lile your environment and the way you run osync ?
Maybe even run DEBUG=true osync.sh and post its logs ?
I get the same error that I've been ignoring for a long time now, but decided to take a look at it today.
Evidently I don't know the code as well as @deajan, but I couldn't see where the variable $ALWAYS_SEND_MAILS
gets initialized no matter what
This statement only seems to hold true if the following condition is met first:
## Here we set default options for quicksync tasks when no configuration file is provided.
if [ $_QUICK_SYNC -eq 2 ]; then
In my case, I do provide a configuration file so I shouldn't enter that condition.
Also noteworthy, is that the variable at line 2347 isn't enclosed in double quotes, compared to most other conditions in the script. So my next automated execution tonight (CRON) will be happening with that small change, adding those double quotes, which should ensure two arguments are provided to the binary operator.
My assumption is that the config file used by @nux1701 is an elder version that doesn't hold the "ALWAYS_SEND_MAILS" variable, hence producing the error. The variable gets initialized only when no configuration file is used.
My assumption is that the config file used by @nux1701 is an elder version that doesn't hold the "ALWAYS_SEND_MAILS" variable, hence producing the error. The variable gets initialized only when no configuration file is used.
That assumption makes a lot of sense, since this is my situation as well. I didn't think to check the new configuration file when upgrading from version 1.2