HTML Forms: Interacting with the Net
SELECT is the next major markup tag. The SELECT tag is used to encapsulate a selection list. Several <OPTION> tags may be included between a <SELECT> and a </SELECT>, to add elements to the list. A selection list may take on two physical forms. If it has a SIZE of one, it appears as a popup menu. If the SIZE attribute is greater than one, it appears as a scrollable list displaying SIZE options one at a time. Here are the possible attributes of the SELECT tag:
Indicates a symbolic name for the selection menu.
The physical number of lines that are visible at any time.
If this attribute is present, multiple items of the list may be selected at one time.
These attributes are straightforward, and I'll leave them for your exploration later. Before we move on, I should mention a little more about the <OPTION> tag. The option tag can have the attribute SELECTED. When present, this attribute indicates that a particular list item is selected by default. The <OPTION> tag is much like the <li> of normal HTML lists; it does not require a terminating </OPTION> tag. Instead, the appearance of an <OPTION> tag indicates the beginning of a new list item and the termination of any preceding items. Also, a selection list item can be only simple text. List items cannot be marked up, nor can they be anchored items.
A form element where a user can type in free-form text, much like entering text into an editor, is constructed using the TEXTAREA tag. A text entry area is has the basic form of:
The default text is the initial text, if any, which is present in the text entry area. This form element has three easy-to-use attributes.
Indicates a symbolic name for the selection menu.
The vertical size of the text entry area.
The horizontal size of the text entry area.
Now that we know what things we have available, let's create a basic form. Listing 1 shows a simple HTML form, while Figure 1(139K) displays how Mosaic might present this form.
Keep in mind that the ACTION attribute needs to specify your host and a valid script or program. In the example, the shell script echo.sh (shown later) will be executed on your.http.host when the form is submitted. The script or program needs to reside in a directory which your server recognizes as a valid location for executable programs. Be sure to check the documentation for your server to be sure it is configured properly to allow for this sort of execution. A typical location for these sorts of programs is in the cgi-bin directory under the server root, and that is how this example is configured.
The form is only one of the three parts necessary to interact with a user. The second is the http server, which we will not cover here (please refer to the documentation for your server). The third is a CGI program or script. As mentioned above, these programs must reside in a directory recognized by the http server as a valid location for executables. A CGI program needs to be able to understand the encoded form data as it is returned from a client, and must be able to respond appropriately. The encoded form data will appear either on the command line or in the environment variable QUERY_STRING, depending on whether a METHOD of GET or POST is used. Typically, a program needs only write the necessary response on stdout, and the response will then be transmitted back to the client by the http daemon.
A number of environment variables are also typically set by the server for the CGI program's use. Following is a partial list of environment variables that I find useful. Please refer to hoohoo.ncsa.uiuc.edu/cgi/env.html for further discussion of other environment variables.
Set to the METHOD used to make the request.
Set to the encoded form data when the GET METHOD is used.
Set to the remote hostname if available.
Set to the IP address of the remote host.
The length of the data returned in a client's query.
Usually, a CGI program need only respond to a request with an appropriate http header, possibly followed by a document. The response is simply written on stdout, where the data will be returned to the client. A header consists of an http header directive followed by a relevant text string. The header is terminated by a blank line. Two of the most used header directives are the Content-type and Location directives. The Content-type directive indicates the type of data which is to follow. For example, Content-type: text/html indicates that the document which follows the header on stdout is written in HTML. The Location directive is used to provide a means by which redirection can take place. For instance, Location: http://goto.another.host/web/doc.html would cause a client to retrieve the document specified in the URL.
Probably the easiest way to explore the construction of a CGI program is with an example. Listing 2 shows a shell script which will respond to a client's HTML form request.
The response is to echo the encoded query, some of the environment variables, and the decoded content of the query. This program is useful as a test program when creating new forms, and as a base for building other CGI scripts. Figure 2(135K) displays the results of posting the form shown in Figure 1 to this script.
Examine the QUERY_STRING in Figure 2 Notice that spaces are encoded as addition signs, and that an ampersand in the input is encoded as a hex value preceded by a percent sign. Also notice that each name/value pair is separated by an ampersand. The shell script decodes this string back into the data as it was entered by the user. There are other programs, such as CERN's cgiparse, which will also help you decode CGI form data.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Non-Linux FOSS: Caffeine!
- Tech Tip: Really Simple HTTP Server with Python
- Doing for User Space What We Did for Kernel Space
- Rogue Wave Software's Zend Server
- Parsing an RSS News Feed with a Bash Script
- SuperTuxKart 0.9.2 Released
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide