Bug #2402

rc.stop_packages synxtax error when executed

Added by Jim P almost 2 years ago. Updated almost 2 years ago.

Status:Resolved Start date:04/28/2012
Priority:Normal Due date:
Assignee:- % Done:

100%

Category:Web Interface
Target version:2.1
Affected version:2.1 Affected Architecture:

Description

PHP appears to be choking on the new changed syntax in /etc/rc.stop_packages. It's giving a syntax error when executed, even though php -l says the code contains no syntax errors.

The error is:

Parse error: syntax error, unexpected '=' in - on line 42 

However there is no real error there. If you put any code in there, an echo, a global statement, etc, it chokes on it, even if you cut out any other PHP code ahead of it. If you revert the changes made to rc.stop_packages in 0124456b0c4d602adea538cee35fc67c977e9f2e the behavior from #1564 comes back where it will exec fine from the shell but will not reboot from the GUI.

I ran out of time to debug it today -- if someone else has any ideas, have at it. Otherwise I'll poke at it next week.

Associated revisions

Revision 60dd7649
Added by Jim P almost 2 years ago

Move the stop_packages code to a function, and call the function from the shell script, and call the function directly for a reboot. Fixes #2402 and ticket #1564

Revision cb01726c
Added by Jim P almost 2 years ago

Move the stop_packages code to a function, and call the function from the shell script, and call the function directly for a reboot. Fixes #2402 and ticket #1564

History

#1 Updated by Jim P almost 2 years ago

  • Description updated (diff)

#2 Updated by Jim P almost 2 years ago

Looks like that syntax:

/usr/local/bin/php -q <<ENDPHP
...
ENDPHP

Is being interpreted by the shell and all of the $vars are being stripped among other changes. This didn't even work on 2.0.x either, so it's not a recent problem. We'll have to go back to the other syntax (calling with php -f) since to make this work we'd have to shell escape the entire source of the script, which would be ugly and hard to maintain.

Which means that the behavior from #1564 will return unless we can figure that out. Might be better to close this out and reopen #1564.

#3 Updated by Jim P almost 2 years ago

  • Status changed from New to Feedback
  • % Done changed from 0 to 100

#4 Updated by Jim P almost 2 years ago

  • Status changed from Feedback to Resolved

This has been working fine for me since my last fix. No errors, and it runs as expected during shutdown.

Also available in: Atom PDF