California State University, Northridge Effects Of

Total Page:16

File Type:pdf, Size:1020Kb

California State University, Northridge Effects Of CALIFORNIA STATE UNIVERSITY, NORTHRIDGE EFFECTS OF ALGORITHM DESIGN ON PROGRAM DEVELOPMENT AND MODIFICATION A project submitted in partial satisfaction of the requirements for the degree of Master of Sciences in Computer Science by Marc K. Thompson January, 1983 The Project of Marc K. Thompson is approved: Jack/Alanen v G. , ichael Barnes, Chairman California State University, Northridge ii TABLE OF CONTENTS Page LIST OF TABLES • • • • • • • . v LIST OF FIGURES AND PROGRAMS • • • . vi Section 1. INTRODUCTION . 1 The Software Life Cycle •. 3 Elements of a Good Design 7 Research on Algorithm Design and Program Development • • • • • • • . 8 A Hierarchy of Programming Errors • . 13 Methodology issues for Experimental Software Engineering •••••• . 15 2. THE EXPERIMENT . 18 Statement of the Research Question . 18 General Hypothesis . 20 Method . 21 Subjects . 21 Course and Apparatus . 22 Program Tasks • . 24 Design . 26 Sampling Bias • . 31 Results for the Statistic Program • . 32 Results for the Encryption Program 36 Conclusion about Algorithms and Errors 41 Experimental control and the Experiment Investigation of Programming • • • • • 46 Future Research • • • • • • • • • • • • • 47 iii Section Page Generalized Summary • • • • • • • • • . 48 3. AN EXPERIMENTAL PROGRAMMING INTERFACE • • • 51 Procedure Routines . 55 Programs . 58 Conclusions • . 65 REFERENCES . 66 iv LIST OF TABLES Table Page I. Survey of the Languages . • • . 68 II. Survey of Average Number of Programs . 68 III. Means of Errors by Breakpoint Intervals . • . 69 IV. Means of Errors by Experimental Groups . • . 70 v. Correlation Matrix of the Three Types of Errors • • • • • • • • • . 71 VI. Means and Standard Deviations for Program Analysis • • • . 72 VII. Time Measures of the Three Graphs 73 VIII. Correlation Matrix for the Overall Analysis • 74 v LIST OF FIGURES AND PROGRAMS Figure Page 1. Example of Bubble Sort Algorithm ••••• . 75 2. Graph of Error Life Cycle: Syntax Errors . • 76 3. Graph of Error Life Cycle: Semantic Errors 77 4. Graph of Error Life Cycle: Logical Errors 78 5. Graph of Error Percentage: Program 1 • . 79 6. Graph of Error Percentage: Program 2 . • 80 7. Graph of Error Percentage: Program 3 . • . • 81 8. Graph of Error Percentage: Program 4 • . 82 Procedure Routine for Experimental Interface Page 1. XEDIT . 83 2. LIST . 83 3. RUN . 84 4. BYE . 86 Program for Experimental Interface Page 1. CALCUL • . 87 2. COMBIN • . 91 3. DATER . 91 4. TOTALS • . 92 5. CONVERT . 94 6. BREAK . 96 7. SEARCH • . 98 8. Plotting Program . • • • 104 vi ABSTRACT EFFECTS OF ALGORITHM DESIGN ON PROGRAM DEVELOPMENT AND MODIFICATION by Marc K. Thompson Master of Sciences in Computer Science A study of the effects of an algorithm on subsequent program development was conducted. More specifically, the general hypothesis was that if more time was devoted to algorithm design prior to coding, then less effort would be required during the testing stage. A three (algorithms) by five (intervals) MANOVA design was used to test the hypothesis. The independent variables were three styles of algorithm design (ALGORITHM-BEFORE, WITH-ALGORITHM, and NO-ALGORITHM) representing when an algorithm was specified and five vii task intervals representing each subject's programming effort. The dependent variables were the three types of errors (syntax, semantic, and logical) described by Young [1973] that were committed by the subjects in the testing stage. Two experiments, and a replication of both experiments, investigating program development and modification were conducted using 30 subjects. The subjects were divided into three groups, by algorithm design style. The experimental results supported the general hypothesis that if more effort was devoted to program design, prior to coding, then less effort was required in the testing stage. The results for both program development and modification generally supported the hypothesis that fewer logical errors would be committed with a fully-designed algorithm. The results for syntactic and semantic errors were inconclusive. In addition Young's [1973] intuitive notion of syntax errors precede semantic errors which in turn precede logical errors was supported. Lastly, a description of the experimental programming interface that was used to conduct these experiments. This interface was extended for future research on program development. viii INTRODUCTION This report is divided into three sections. The first section is an introduction to the research. The second section is a discussion of two experiments measuring the effects of algorithm design on program development and modification. The third section describes the software used to create an experimental programming interface. This interface was used for the collection and analysis of the data described in the experiments. The actual research project (section two) was divided into two different experimental tests. One test was the development of a new program and the second test was the modification of the program created in the first test. Two replications of these experimental tests were made. Thus there are four analyses of two original program development tasks (programs 1 and 3) and two modification of existing program tasks (programs 2 and 4). Program 2 was a modification of program 1, and program 4 modified program 3. The purpose of this research project was to study the effects of prior algorithm design on novice programmers's subsequent software development. This effect has become an important aspect to programmers. The overall design of a program is specified by the 1 2 algorithm created. The more specific the algorithm is with respect to the logic of the program's requirements, the better the algorithm should guide the programmer. This effect is similiar to an outline for a writer of a paper, in that the outline guides the flow of information to the reader and directs them to the goals of the paper. A secondary purpose was to create a software interface that could be used to gather data for experiments on program development. Certain specifications were required to make the experimental interface a naturalistic environment for observing the subject's programming efforts. These specifications were as follows: compatibility to the host environment, ability to perform operational system functions while recording programming efforts, and to facilitate data analysis. This special interface will be discussed later in section 3 since it is supportive to the following experiments but not central to the hypotheses investigated. Clearly, the effects of prior algorithm design on programming effort are dependent upon the skill of the programmer at using algorithms [Brooke and Duncan, 1980]. Novice programmers have limited experience in using algorithms. Because of that fact, it is important 3 to get some measurements on the initial efforts of novice programmers learning to design and implement algorithms in computer programs. Hopefully these measurements will be an aid in the teaching of problem solving with algorithms and programming. The diversity of people who are now using computer systems to do their work has increased the demand for better and more efficient teaching methods. Before presentation of the experiments, a brief discussion of the motivation for such research and a review of relevant literature is necessary. This introduction will focus on the software life cycle, past research efforts, and a hierarchical taxonomy of errors encountered in program development and modification. The Software Life Cycle In the creation of software, the programmer generally follows six stages of development. These stages are collectively called the software development life cycle. The six stages are requirements, specifications, design, coding, testing, and maintenance. The programmer starts with the requirement analysis stage followed by the specification stage. From the specifications, an algorithm is developed in 4 the design stage and this algorithm guides the coding stage. The requirements, the specifications, and the algorithm design direct the coding and testing stage. The users of the system dictate the final stage of operation and maintenance. Zelkowitz [1978] gave a rough estimate of the effort required by the various developmental stages. The requirement analysis and specification stages each take ten percent of the effort, design takes fifteen percent, coding takes twenty percent, testing takes twenty-five, and operation, excluding maintenance, takes twenty percent. If maintenance on a large scale system is included in the effort, it would take about two-thirds of the total effort. A widely held belief in software engineering is that more effort devoted to the requirements, specifications, and design stages will reduce the necessary effort in the coding, testing, and maintenance stages of the software life cycle. The significant stages of the software life cycle to this study are design, coding, testing, and maintenance. Usually, the requirements and specification are given to the novice programmer, so these stages will not be discussed. This is not to say that these stages are unimportant to programmers, but rather, they do not play a significant role in this 5 research. A brief discussion of the software life cycle as it pertains to the novice programmer is relevant to the understanding of the effects of an algorithm on software development. The design stage in the academic environment usually involves a flowchart or psuedo-code algorithm of some type. The algorithm is an abstract and
Recommended publications
  • Rexx Hands-On Lab
    1 2 Welcome to the Introduction to Rexx Hands-on Lab. This lab will cover a series of topics about the Rexx language. At the end of each topic, there will be exercises that use the concepts covered in the charts and text for that topic. The solutions for the exercises are in Appendix A. This is not a graded class or lab so you are free to refer to the solutions if you would like or if you need help with any of the exercises. Also, if you need assistance with any of the lab material or exercises, please raise your hand and someone will come to assist you. 3 These are the exercises that you will be doing today. There are 2 PDF files on your desktop that you might find helpful as you work on the exercises: • REXX Reference will help you with statement syntax and usage • Appendix H is a summary of XEDIT commands that might be helpful when you are writing and updating your Rexx programs 4 This section introduces the Rexx Language and explains how to create and execute Rexx programs on z/VM and TSO systems. It also includes some z/VM hints to help you with today's exercises. 5 REXX is a nickname for Restructured eXtended eXecutor. The Rexx language was designed to be intuitive, easy to read, and easy to follow a program's logic. Rexx programs can be very simple, ranging from personal tools and utilities such as "scripts" of commands that you might run every day to set up your system or run test cases, to very complex programs that might be part of a licensed product.
    [Show full text]
  • Using REXX to Build a Front-End User Interface Han-Li Lee, United Illuminating Company
    220 Host Operating Systems Using REXX to Build a Front-end User Interface Han-li Lee, United Illuminating Company present a problem fclo those who do not have any Abstract knowledge or training in SAS language. A user­ This paper presents the UISSP (UI Social Suppon friendly system is thus required. Since back in early Programs) System, a menu-driven reporting system 1986 UI had not installed SAS/AF yet, the author using IBM's REXX (Restructured EXtended eXecu­ then decided to use REXX to build a user-friendly tor) language, base SAS e, and SAS/FSP e (SAS front-end interface. UISSP system, to allow the user version 5.18 under CMS operating system) for the to enter the data and run reports easily. United lliuminating Company, an electric utility company located in New Haven, Connecticut. The Running the UISSP System System uses the REXX to write a front-end user REXX is a general pwpose, high-level language. interface to the SAS System. It creates new files, This interface program is written in a REXX lan­ updates existing files, and produces reports. This guage EXEC, with a filename UISSP and a filetype paper shows the techniques used for building such a EXEC. It contains CP and CMS commands. REXX user-friendly reporting system. It will also compare programs are executed by an interpreter without fiJ'St the use of REXX and SAS/AF ® in building menu­ being translated into another form. This program is driven systems. written under the host system CMS. To stan running the system, the user just types a word "uissp," the Background filename of the EXEC, at the command line.
    [Show full text]
  • Real World Z/VSE to Z/OS Migration Experience from a Z/VSE Bigot
    Honesty | Loyalty | Integrity | Quality z/VSE to z/OS Migration Experience From a z/VSE Bigot’s Perspective Tony Thigpen – Senior System Programmer Agenda . Customer Background . Methods . Source Conversion . JCL Conversion . Utility Conversion . Operations Conversion . Data Conversion . Training . Issues that were discovered sooner or later . Discussion . Wrap Up Customer Background . Manufacturer located in Mississippi and North Carolina . Initial Configuration: o Z9 in MS running 4 z/OS LPARs (mix of 1.4 and 1.7) – 160mips o Z10 is NC running 5 VSE/ESA LPARs (1.5) – 70mips o Multiple AS/400s in different locations . First major changes o Both CPUs and some AS/400s were relocated to PZG facilities in FL . Second major changes o 3 of the VSE LPARs were slowly migrated off-platform o 2 VSE LPAR was merged into 1 VSE LPAR o All but one of the AS/400s located in FL were eliminated o All z/OS LPARs upgraded to 1.12 to allow them to run on a Z10 . Resulting Configuration: o Z9 in FL running 4 z/OS LPARs (all 1.12) – 150mips o Z10 in FL running 1 VSE/ESA LPAR (1.5) – 70mips Customer Background . Customer goal to cut costs o An os for each machine from IBM ($$) o Adabas for each machine ($$$) o Similar Third-party software on both machines ($$$) o Maintenance, floor space, HVAC costs ($$) o Operations (staff) costs ($) . Customer was concerned with older VSE/ESA o Out of Service o CICS/VS – CICS/TS conversion . The decision was to take the money budgeted for upgrading the VSE and use it instead to migrate the one remaining VSE LPAR to z/OS o Unpopular with VSE programmers but there were only 3 left.
    [Show full text]
  • Programmable Command Languages for Window Systems Egie
    Programmable Command Languages for Window Systems Rlchard Joel Cohn CMU-CS-88-139 June 1988 _egie Programmable Command Languages for Window Systems Report number CMU-CS-88-139 Copyright © 1988 by Richard Joel Cohn. All rights reserved. This dissertation was submitted in partial fulfillment of the requirements for the degree of Doctor of Philosophy in Computer Science at Carnegie Mellon University. The research in this dissertation was supported by the Information Technology Center, a joint project of Carnegie Mellon University and International Business Machines Corporation. This dissertation was produced with Scribe. Illustrations were produced with Pic, Troff, and TranScript. Aldus and PageMaker are trademarks of Aldus Corporation. Apple and Macintosh are registered trademarks of Apple Computer, Inc. Clads is a trademark of Clads Corporation. DEC is a trademark of Digital Equipment Corporation. Hypercard is a trademark of Apple Computer, Inc. IBM is a registered trademark of International Business Machines Corporation. MacDraw, MacPaint, and MacWrite are registered trademarks of Clads Corporation. NeWS and Sun-3 are trademarks of Sun Microsystems, Inc. PostScript and TranScript are trademarks of Adobe Systems, Inc. Scribe is a registered trademark of Scribe Systems. SmaUtalk-80is a trademark of Xerox Corporation. Tempo is a trademark of Affinity Microsystems, Ltd. UNIXis a registered trademark of AT&T Bell Laboratories. Abstract Programmable command and macro languages have long served as important tools for users of computer systems. This thesis describes the design and implementation of a general-purpose command language for a window system. This has never been tried be- fore because these systems are new and because the problems inherent in providing a command language for a window system are hard.
    [Show full text]
  • VM/SP Introduction.Pdf
    GC19-6200-1 File No. S370/4300-20 Program Product GC19-6200-1 File No. S370/4300-20 IBM Virtual Machine/ System Product: Program Product Introduction Program Number 5664-167 Release 2 -----~- - i::~~ Second Edition (April 1982) This edition, GC19-6200-1, is a reV1S10n of GC19-6200-0. It applies to the IBft Virtual ~achine/System Product (5664-167) until otherwise indicated in new editions or ~echnical Newsletters. Changes are continually made to the information contained herein; before using this publication in connection with the operaticn of IBft systems, consult the IB~ 2:i2tem/370 and .!!300 f!:~.§§£!§ Bibli.£g~, GC20-0001, for the editions that are applicable and current. For a list of changes, see page iii. Technical changes or additions to the text cr illustrations are indicated by a vertical bar to the left of the change. It is possible that this material may contain reference to, or information about, IB~ products (machines and programs), programming, or services that are not announced in your country. Such references or information must not be construed to mean that lEft intends to announce such IB~ products, programming, or services in your country. Publications are not stocked at the address given below; requests for IB~ publications should be made to your IBft representative or to the IB~ branch office serving your locality. A form for reader's comments is provided at the back of this publication. If the torm has been removed, comments may be addressed to IB~ Corporation, Programming Publications, Department G60, P.O. Box 6, Endicott, New York, U.S.A.
    [Show full text]
  • System Productivity Facility (ISPF) and ISPF/Program Development Facility
    GC34-2172-3 Interactive System Productivity Facility (ISPF) and ISPF/Program Development Facility What's New in ISPF? Version 2 Release 3 MVS Version 2 Release 2 VM/SP I , . .. GC34-2172-3 Interactive System Productivity Facility (ISPF) and ISPF/Program Development Facility What's New in iSPF? Version 2 Release 3 MVS Version 2 Reiease 2 VM/SP I Fourth Edition (July 1987) This edition applies to Version 2 Release 3, of the program products Interactive System Productivity Facility (ISPF) ^ (5665-319), and Interactive System Productivity Facility/Program Development Facility (ISPF/PDF) (5665-317), and to all subsequent releases and modifications of both until otherwise indicated in new editions or Technical Newsletters. In the 370 environment, they are for use with with MVS/SP Version 1.3.5 or later. In the Extended Architecture (XA) environment, they are for use with MVS/SP Version 2.1.2 or later. This edition also applies to Version 2 Release 2 of the program products Interactive System Productivity Facility (ISPF) (5664-282), and Interactive System Productivity Facility/Program Development Facility (ISPF/PDF) (5664-285), and to all subsequent releases and modifications of both until otherwise indicated in new editions or Technical Newsletters. They are for use with VM/SP Release 3. With Double-Byte Character Support (DECS), they are for use with VM/SP Release 4. Changes are made periodically to the information herein; before using this publication in connection with the operation of IBM systems, consult the latest IBM Systeml370 and 4300 Processors Bibliography, GC20-0001, for the editions that are applicable and current.
    [Show full text]
  • Unit 2 Basics of C
    Basics of C UNIT 2 BASICS OF C Structure 2.0 Introduction 2.1 Objectives 2.2 What is a Program and what is a Programming Language? 2.3 C Language 2.3.1 History of C 2.3.2 Salient Features of C 2.4 Structure of a C Program A simple C Program 2.5 Writing a C Program 2.6 Compiling a C Program 2.6.1 The C Compiler 2.6.2 Syntax and Semantic Errors 2.7 Link and Run the C Program 2.7.1 Run the C Program through the Menu 2.7.2 Run from an Executable File 2.7.3 Linker Errors 2.7.4 Logical and Runtime Errors 2.8 Diagrammatic Representation of Program Execution Process 2.9 Summary 2.10 Solutions / Answers 2.11 Further Readings 2.0 INTRODUCTION In the earlier unit we introduced you to the concepts of problem-solving, especially as they pertain to computer programming. In this unit we present C language - a standardized, industrial-strength programming language known for its power and portability as an implementation vehicle for these problem solving techniques using computer. A language is a mode of communication between two people. It is necessary for those two people to understand the language in order to communicate. But even if the two people do not understand the same language, a translator can help to convert one language to the other, understood by the second person. Similar to a translator is the mode of communication between a user and a computer is a computer language.
    [Show full text]
  • Solaris X Window System Reference Manual
    Solaris X Window System Reference Manual Sun Microsystems, Inc. 2550 Garcia Avenue Mountain View, CA 94043 U.S.A. 1995 Sun Microsystems, Inc., 2550 Garcia Avenue, Mountain View, California 94043-1100 USA. All rights reserved. This product or document is protected by copyright and distributed under licenses restricting its use, copying, distribution and decompilation. No part of this product or document may be reproduced in any form by any means without prior written authorization of Sun and its licensors, if any. Portions of this product may be derived from the UNIX system, licensed from UNIX System Laboratories, Inc., a wholly owned subsidiary of Novell, Inc., and from the Berkeley 4.3 BSD system, licensed from the University of California. Third- party software, including font technology in this product, is protected by copyright and licensed from Sun's Suppliers. RESTRICTED RIGHTS LEGEND: Use, duplication, or disclosure by the government is subject to restrictions as set forth in subparagraph (c)(1)(ii) of the Rights in Technical Data and Computer Software clause at DFARS 252.227-7013 and FAR 52.227-19. The product described in this manual may be protected by one or more U.S. patents, foreign patents, or pending applications. TRADEMARKS Sun, Sun Microsystems, the Sun logo, SunSoft, the SunSoft logo, Solaris, SunOS, OpenWindows, DeskSet, ONC, ONC+, and NFS are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries. UNIX is a registered trademark in the United States and other countries, exclusively licensed through X/Open Company, Ltd. OPEN LOOK is a registered trademark of Novell, Inc.
    [Show full text]
  • Ntm.Alttttr I Volume 13 Number 9 September, 1979
    /1 ) ~ j ,.. ) Uniersity Computer Center Newsletter I i UNIVERSITY COMPUTER CENTER UNIVERSITY OF MINNESOTA-TWIN CITIES MINNEAPOLIS, MINNESOTA 55455 contents bulletins CHANGE/6400/170-720/* P• 74 MERITSS up and running, no problems An additional "Introduction to UCC" class will be held on Tuesday, September 25th, 2:15-3:15 in NEW VERSION OF XEDIT P· 74 Mechanical Engineering 108. This will be an Highlights of Xedit 3.1 abbreviated version of tne October 5th class and is intended for users of the UNITE educational DATA BASE MANAGEMENT P· 75 system, however, other.; are 1o1elcome to attend. User group proposed, System 2000 notes VIDEO TAPE COPIES P· 75 Costs you more FOR SALE P• 75 USAGE STATISTICS p. 76 D 0 N' T FORGET THE SYSTEM CHANGE SHORT COURSE DESCRIPTIONS P· 77 I f SEE WRITEUP,UPGRADE. ntm.alttttr I Volume 13 Number 9 September, 1979 Director: Peter c. Patton Editor : Amy Koepke Comments about the content ot this newsletter, or suggestions for changes may be directed to the editor, 235a Experimental Engineering, 612/373-7744. The University of dinnesota adheres Lo L1te principle that all persons shall have equal opportunity and access to facilities in any phase of University activity 1o1ithout regard to race, I creed, color, sex, or national origin. I Copyright University of Minnesota, 1979. Permission to copy is hereby granted, provided that proper ackno1o1ledgement is given. ---------------------~~------ • - ,_J__.- ------------------- ~ . September, 1979 UCC NEI>/SLJ::TTER Page 73 s~veral powerful new commands have been added to During the weekend of August 25-26 a CDC Cyber provide XEDIT with text formatting capabilities.
    [Show full text]
  • The Basics of Using Z/VM
    Brian W. Hugenbruch, CISSP z/VM Development Team, IBM: Endicott, NY, USA The Basics of Using z/VM © 2010 IBM Corporation Trademarks The following are trademarks of the International Business Machines Corporation in the United States, other countries, or both. Not all common law marks used by IBM are listed on this page. Failure of a mark to appear does not mean that IBM does not use the mark nor does it mean that the product is not actively marketed or is not significant within its relevant market. Those trademarks followed by ® are registered trademarks of IBM in the United States; all others are trademarks or common law marks of IBM in the United States. For a complete list of IBM Trademarks, see www.ibm.com/legal/copytrade.shtml: *, AS/400®, e business(logo)®, DBE, ESCO, eServer, FICON, IBM®, IBM (logo)®, iSeries®, MVS, OS/390®, pSeries®, RS/6000®, S/30, VM/ESA®, VSE/ESA, WebSphere®, xSeries®, z/OS®, zSeries®, z/VM®, System i, System i5, System p, System p5, System x, System z, System z9®, BladeCenter® The following are trademarks or registered trademarks of other companies. Adobe, the Adobe logo, PostScript, and the PostScript logo are either registered trademarks or trademarks of Adobe Systems Incorporated in the United States, and/or other countries. Cell Broadband Engine is a trademark of Sony Computer Entertainment, Inc. in the United States, other countries, or both and is used under license therefrom. Java and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the United States, other countries, or both. Microsoft, Windows, Windows NT, and the Windows logo are trademarks of Microsoft Corporation in the United States, other countries, or both.
    [Show full text]
  • Basic CMS and Z/VM Commands
    Basic CMS and z/VM Commands Velocity Software provides a cloud architecture for education and demonstration purposes. This allows users to create CMS servers and Linux servers using our zPRO product, and then use those servers for the duration of their self study education. It also allows for demonstration of our zPRO product. zPRO is Velocity Software's Cloud Enablement product, allowing end users to define and manage their servers without having z/VM knowledge. zPRO supports a private cloud for z/VM that includes support for Linux servers, CMS users, and 2nd level z/VM systems This paper describes the some of the basic CMS and VM commands as an introduction to using the IBM mainframe. The topics covered are: • 3270 keyboard • CMS help command • CMS query command • CMS xedit command • CMS filelist command • CMS profile exec file • CMS profile xedit file • CMS REXX commands More detailed information is available in these documents: • IBM Redbook - Introduction to the New Mainframe: z/VM Basics at http://www.redbooks.ibm.com/abstracts/sg247316.html?Open” Chapter 1 to 5 can give you an quick overview. The CMS commands you could work with, are in chapter 6. • IBM Library at https://www.ibm.com/support/knowledgecenter/SSB27U_6.4.0/ com.ibm.zvm.v640.hcpa0/liboper.htm#liboper z/VM V6.4 CMS Commands and Utilities Reference, SC24-6166 z/VM V6.1 CMS Primer, SC24-6172 z/VM V6.4 CMS User's Guide, SC24-6173 z/VM: REXX/VM Reference , SC24-6221 z/VM: REXX/VM User’s Guide , SC24-62 3270 Keyboard This section documents the special keys used by z/VM and CMS, that are set up on x3270 or TN3270 emulators.
    [Show full text]
  • UNIX Commands Reference
    Mail Tools Special Command elm Sends and displays mail messages Line Characters Unix mailx Sends and displays mail messages > Redirect standard output to the file; erase mutt Sends and displays mail messages the file first Reference pine Sends and displays mail messages >> Redirect standard output to the file; xbiff Displays a mailbox and flag image on an append to the file X window when mail has arrived < Redirect standard input from the file Card | Pipe the standard output from one Text Editors command to the next A helpful reference to Unix commands on the CECS emacs Text Editor ? Single character wildcard Unix computers. gvim Graphical version of vim * Multiple character wildcard pico Text Editor [...] One of ... wild card vi Text Editor ; Command separator vim vi improved - Text Editor . Current directory xedit Simple Graphical Text Editor .. Parent directory xemacs Graphical version of emacs [gnu] / Directory level separator Text Processing Tools & Run command in the background http://www.cat.pdx.edu $ Begin shell variable name cat Concatenate (list) a file [email protected] = Shell variable assignment cut Displays specified parts from each line of a file dos2unix Convert text file from DOS format to Filename Expansion Program descriptions followed by [packageName] UNIX format Characters indicate which package the program is located in head List the beginning of a file ispell Spelling checker * Matches any characters (0 or more) Packages less Similar to more, but allows backward ? Matches any single character movement [...] matches any character in the enclosed list Packages configure the user's environment based on more List a file page by page or range what software he/she wants to use.
    [Show full text]