running-php-on-rucs
running php on rucs
(not using a web server)

We will look at:

#reviewing-a-few-linux-commands
#accessing-rucs
#running-php-from-the-command-line
#how-to-edit-files-on-rucs

video from distance lecture (breeze), 2017-jan-24b (0h30m): syllabus-review; running php @ 0h21m

Reviewing a few linux commands

You'll want to be familiar with the main options for the following:

ls -lF — list files in long format (show permissions/timestamp); use -d to show directories themselves (rather than their contents).
cd — change directory
mkdir — make a directory
chmod — change (permission) mode
Optionally, any editor that can be run through a terminal window:
- nano — not a great editor, but most of its commands are listed at the bottom of the screen, making it easy to learn;
- emacs — the kitchen sink of editors — great, but it involves memorizing commands like ctrl-S to search, ctrl-X ctrl-S to save, ctrl-C ctrl-C to compile and run the Java program you are editing, and ctrl-u tetris to play a game (seriously).
- vim — an editor which can let you edit extremely quickly, once you master the fact that it has “input mode” (where your keystrokes add characters to your file, just like you'd expect), and “command mode” (where each keystroke is an editing command — e.g. j moves down a line and k moves up a line … a keybinding that also happens to work in gmail when viewing your list of messages, btw).
Tutorials for any of of these editors are easily searchable.

If you want to brush up (or, learn) basic unix, this is a good tutorial (sections 1,2 on using teh command-line for file basics, and section 5 for file permissions).

Accessing `rucs`

Before we even revisit the code, let's talk about the machine rucs.radford.edu (“radford university computer science”): it's a machine for use by ITEC department students, and is a compute-server which you can access from anywhere.

How to log on to rucs, so that you can run php on it:
First, start the VPN, if you are off campus. Then, either use ssh yourUserName@rucs.radford.edu or run putty. Note that if rucs is down, then ruacad.radford.edu can also be used.

Be aware: rucs is not the campus web server, nor the php server! You don't have accounts on those machines (although your H: drive is shared by those machines). In particular: the version of php you run from rucs's command-line is slightly different than the version run by php.radford.edu !-o

Running PHP from the command line

Once logged on to rucs, it is straightforward to run a php program:

If you have a php file in your current directory, then just enter php filename.php.
It's also often handy to just want to try a quick PHP code-fragment to experiment: type php -a for a quick interactive session.

However, this raises the question of how to get your php program-files onto your H: drive in the first place.

How to edit files on rucs

Either

From your PC, mount your H: drive and then edit locally (using Notepad or JEdit or eclipse... but not Word). Each time you save your file, it's writing to your H: drive.
log in to rucs in a terminal-window, and edit the file locally (vim, emacs, or pico).

I do not suggest editing the file locally, and then scp’ing them over after each edit.

Note that if you have your own computer and have installed XAMP, it includes a PHP interpreter (that's the ‘P’ in “XAMP”). So you may find it easy to
However, you'll still need to know how to connect to rucs and run php there: the reason is that the rather-quite-old version of PHP installed on rucs is much closer to the old version of PHP used by php.radford.edu. So when debugging, you'll want to be able to run PHP using the exact H: files and the similar php version as the web server uses.

splitting into multiple files

Video: require_once (18m47s)

We can take blend.php (src), and separate the code from the test-cases: utils.php (src), and separately utils-test.php (src). The directive require-once is a run-time instruction which just goes to the require'd file and (effectively) splices it into the current file, and continues evaluating line-by-line. (So it's reminiscent of java's import, but require-once significantly more simple-minded. Beware trampling on identifiers, and it's poor practice to have any dangling tags / code in the require'd file.)

This also lets us separate a program that uses blend from the test cases: some-web-page.php (src), and some-web-page.php (output).

XHTML

xhtml: Even though original HTML doesn't require the following, they are best practices, and they are required for this class:

Tag names are case-sensitive (with a preference for lower-case and camelCase).
quote all attribute-values, even if it looks numeric;
well-formed (duh): each open-tag must be eventually followed by a corresponding close-tag, and if a tag's body contains another open-tag it must also contain the corresponding close-tag.
- Bad: This is <em>not <strong>at all</em> legal</strong> XML.
- Good:This is <em>actually <strong>very</strong> good</em> practice.
Another way of viewing this: The open/close tags must correspond to a tree.
The most common (non-X)HTML example using improperly nested tags is <p>, which (in HTML) doesn't need to be closed; the browser auto-closes the tag when it reaches the next <p> (or more precisely: when it reaches the next block-level open-tag, or a close-tag which is terminating the enclosing block, e.g. if the paragraph was already inside an itemized list).

Browsers tend to go to great lengths to try to make sense of tag soup; just because a page looks fine in your browser doesn't mean it's legal. The result is that many people learned their HTML by doing a show-source on bad, illegal examples, and then propagating that bad HTML, and never realizing it because most browsers still did something reasonable (although the details of how a browser handled bad HTML are of course entirely non-standard).
Note that xhtml is always valid html5 (but not vice versa — for example, unclosed p tags are allowed in html5).
Self-closing tags:
- <br></br>— fine, but long-winded.
- <br/>— self-closing tag, allowed by XML.
- <br />— Used for backwards compatability. The original HTML required a space before the /, and it's conceivable (if unlikely) that a modern browser will insist on using the HTML standard.
  
  We will not worry about such archaic cruft for this class, but your future employers might well care about customers who use old browsers.
- <br> </br>— (note the space inside the tag) this version is not equivalent (and, not valid HTML) — spaces are part of your XML text, even if an HTML browser chooses often ignore them for layout purposes.
Important: In HTML (and actually enforced! by most modern browsers), you can only use the self-closing tag for those tags which never are allowed a body. For tags that may or may not have a body (notably: script), you cannot use the self-closing version even when you want an empty body.
- <hr />— fine; hr never has a body.
- <img src="foo.jpg" />— fine; img never has a body.
- <script type="text/javascript" src="foo.js"></script>— fine.
- <script type="text/javascript" >callSomeFunction();</script>— fine.
- <script type="text/javascript" src="foo.js" />— BAD; a browser may ignore the tag entirely!, which is an annoyingly difficult bug to track down.
There is no good reason for HTML to be defined like this!

running-php-on-rucs running php on rucs(not using a web server)