ITEC 325 2017spring ibarland

home—lects—hws
D2L—breeze (snow day)

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

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.

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.
Or:
• log in to rucs in a terminal-window, and edit the file locally (vim, emacs, or pico).

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

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).

Running a php file via the web

Note:We won't demo this in class yet, since it is not required for hw01. (And hw01 doesn't do this because it's important to be able to run your php programs without using the web at all, for debugging purposes.)

Recall that when a web-server gets a request, it decides how to respond. For php.radford.edu, some of the configuration rules:

• For requests of the form ~userName/somePath/someFile.php, it looks on userName's H-drive, for the file file dynamic_php/somePath/someFile.php, and it runs that .php program. The program's printed output becomes the response sent back to the browser.
• The .php file must be readable by everybody (since it's being served up to the www), and it must be non-writable by group,other (as a security measure: other users can't implant malware into your php program). Apache runs php with the privileges of the file's owner (su).
• php.radford.edu only accepts secure (https) connections.

Let's put our php program on the web!

• Place the .php file inside dynamic_php/ on your H: drive.
  You may have to create that directory if it doesn't already exist, using mkdir.
• Make sure the file is world-readable, but not group-writable: chmod o+r g-w blend.php. (This makes it other-readable, non-group-writable, without changing any other permissions. You could instead use go-w ugo+r to additionally ensure that it is non-group-writable, and readable by user,group,other; however those are usually already part of the standard default.)
• Make sure all the folders enclosing your file are other-executable-and-executable but not group-writable: chmod o+rx g-w . .., chmod o+x . ...
• One crude way to get things to work: Set every file to be rwx r-x r-x (whether or not it's a folder, .html file, or .php file): Recursively change permissions: chmod -R u=rwx go=rx ~/dynamic_php/ or (using the octal representation of the user/group/other permissions, 111 101 101) just chmod -R 755 ~/dynamic_php/
• If the php interpreter hits an error, the program terminates with no output (so nothing is sent back to the client — status code 500: internal server error)! To change this default, include at the top of your php program:

  error_reporting(E_ALL);

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!

See also:

• Wikipedia's common xhtml errors
• w3.org's validator: validator.w3.org
• Something to make you sad that (x)html5 seems to have won out over xhtml2: xhtml.com/en/future/x-html-5-versus-xhtml-2/.

home—lects—hws
D2L—breeze (snow day)

©2017, Ian Barland, Radford University Last modified 2017.Mar.18 (Sat)

Please mail any suggestions (incl. typos, broken links) to ibarlandradford.edu