Skip to content
This repository has been archived by the owner on Jun 27, 2019. It is now read-only.

sickbeard warning message to console during plugin install: break only meaningful... #14

Open
overbyrn opened this issue Jan 7, 2013 · 3 comments

Comments

@overbyrn
Copy link
Contributor

overbyrn commented Jan 7, 2013

I've been meaning to capture this for ages but since I only occasionally reboot my unraid box, I hardly ever see the message.

Here's a screen grab of the message; http://i.imgur.com/1crYz.jpg

Offending piece of code;

plgdata=cat /boot/config/plugins/sickbeard/sickbeard.cfg | grep PLG_DATACHECK
if [[ $plgdata = "" ]]; then
break
else
sed "/$plgdata^/d" /boot/config/plugins/sickbeard/sickbeard.cfg >tmp
mv tmp /boot/config/plugins/sickbeard/sickbeard.cfg
fi

@overbyrn
Copy link
Contributor Author

I thought I'd squash the error message cause by breaking inside a conditional. I originally planned to switch the conditional logic but then I came to wonder if you still mean for sed to delete PLG_DATACHECK line if found in the cfg file? I ask as a vanilla install of the plugin writes PLG_DATACHECK="yes" to the cfg file, so I'm thinking perhaps the deletion is/was a legacy thing?

@Influencer
Copy link
Owner

Actually not sure how that all got back in, could have sworn I had removed it.When I added the "force update" option it hit the limit of the update.htm for passing variables so I had to remove one. I chose to remove the option to toggle the data check off/on. The deletion of PLG_DATACHECK from the cfg is actually to remove the line from the config for people who are coming from older versions where it was needed. I guess I either forgot to remove it being written in a vanilla install and checking for it before calling the datacheck function, or I merged the change with an older version somewhere along the way.

Your pull request essentially would do the same thing as removing the if condition from around the call to the datacheck function. We should fix the break but removing the checks to the config for that variable would be the ideal way. I'll pull this for now until we can remove the old code

@Influencer
Copy link
Owner

Sorry, didn't realize it wasn't a PR. :p

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants