DOCSLIB.ORG

User Manual for Ox: an Attribute-Grammar Compiling System Based on Yacc, Lex, and C Kurt M

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
User Manual for Ox: an Attribute-Grammar Compiling System Based on Yacc, Lex, and C Kurt M Computer Science Technical Reports Computer Science 12-1992 User Manual for Ox: An Attribute-Grammar Compiling System based on Yacc, Lex, and C Kurt M. Bischoff Iowa State University Follow this and additional works at: http://lib.dr.iastate.edu/cs_techreports Part of the Programming Languages and Compilers Commons Recommended Citation Bischoff, Kurt M., "User Manual for Ox: An Attribute-Grammar Compiling System based on Yacc, Lex, and C" (1992). Computer Science Technical Reports. 21. http://lib.dr.iastate.edu/cs_techreports/21 This Article is brought to you for free and open access by the Computer Science at Iowa State University Digital Repository. It has been accepted for inclusion in Computer Science Technical Reports by an authorized administrator of Iowa State University Digital Repository. For more information, please contact [email protected]. User Manual for Ox: An Attribute-Grammar Compiling System based on Yacc, Lex, and C Abstract Ox generalizes the function of Yacc in the way that attribute grammars generalize context-free grammars. Ordinary Yacc and Lex specifications may be augmented with definitions of synthesized and inherited attributes written in C syntax. From these specifications, Ox generates a program that builds and decorates attributed parse trees. Ox accepts a most general class of attribute grammars. The user may specify postdecoration traversals for easy ordering of side effects such as code generation. Ox handles the tedious and error-prone details of writing code for parse-tree management, so its use eases problems of security and maintainability associated with that aspect of translator development. The translators generated by Ox use internal memory management that is often much faster than the common technique of calling malloc once for each parse-tree node. Ox is a Yacc/Lex/C preprocessor, and is designed to bring attribute grammars closer to the mainstream of Unix-based language development. Ox inherits all of the familiar syntax and semantics of Yacc, Lex, and C. It is relatively easy to convert programs between Ox code and "pure Yacc/Lex/C" code. Ox has been used to build a compiler for a small (eighty grammar rules) block-structured imperative programming language. This document is the main reference for using Ox. Disciplines Programming Languages and Compilers This article is available at Iowa State University Digital Repository: http://lib.dr.iastate.edu/cs_techreports/21 User Manual for Ox:AnAttribute-Grammar Compiling System based on Yacc, Lex, and C by Kurt M. Bischo TR92-30 Decemb er, 1992 Department of Computer Science 226 Atanaso Hall Iowa State University Ames, Iowa 50011 c 1992 Kurt M. Bischo CONTENTS 1 Contents 1 Overview of Use 3 2 Preliminary 4 3 Attribute Declarations 5 3.1 Semantics of Attribute Declarations :: :: :: ::: :: :: :: 6 4 Rules and Attribute Occurrences 6 5 Ox Attribute De nitions 7 5.1 Inherited vs. Synthesized Attributes :: :: :: ::: :: :: :: 7 5.2 Attribute Reference Sections in the Y- le : :: ::: :: :: :: 8 5.2.1 Explicit Mo de : :: ::: :: :: :: :: ::: :: :: :: 8 5.2.2 Implicit Mo de : :: ::: :: :: :: :: ::: :: :: :: 10 5.2.3 Mixed Mo de :: :: ::: :: :: :: :: ::: :: :: :: 10 5.3 Attribute Reference Sections in the L- les : ::: :: :: :: 10 5.4 Cycles ::: :: :: :: :: ::: :: :: :: :: ::: :: :: :: 11 6 Translation into C Co de 12 7 Temp oral Behavior of the Ox-generated Evaluator 12 7.1 Stack Op erations : :: :: ::: :: :: :: :: ::: :: :: :: 12 7.2 Placement of Generated Co de :::::::::::::::::: 13 7.3 Decoration and the Ready Set :::::::::::::::::: 14 8 Programming Style 14 9 Postdecoration Traversals 15 9.1 Example: In x to Pre x Translation : :: :: ::: :: :: :: 15 9.2 General Description :: :: ::: :: :: :: :: ::: :: :: :: 18 9.2.1 Traversal Sp eci cations :::::::::::::::::: 18 9.2.2 Traversal Action Sp eci cations :: :: ::: :: :: :: 18 9.2.3 Traversal Semantics ::: :: :: :: :: ::: :: :: :: 20 CONTENTS 2 10 Macros 22 10.1 Macro De nitions : :: :: ::: :: :: :: :: ::: :: :: :: 22 10.2 Macro Uses :: :: :: :: ::: :: :: :: :: ::: :: :: :: 23 10.3 Example :: :: :: :: :: ::: :: :: :: :: ::: :: :: :: 23 11 Command Sequences for Evaluator Development 24 11.1 Conventions of Naming Ox Output Files : :: ::: :: :: :: 24 11.2 Review: Combining the Outputs of Yacc and Lex :: :: :: 24 11.3 Combined Use of Ox, Yacc, and Lex :: :: ::: :: :: :: 25 11.4 Typical Command Sequences :::::::::::::::::: 25 12 Other Points and Features 26 12.1 Error Recovery :: :: :: ::: :: :: :: :: ::: :: :: :: 26 12.2 Memory Alignment :: :: ::: :: :: :: :: ::: :: :: :: 26 12.3 Stripping Ox Constructs : ::: :: :: :: :: ::: :: :: :: 26 12.4 Preventing Execution of Attribute De nition Co de :: :: :: 27 12.5 Control of Storage Allo cation in the Generated Evaluator ::: 27 12.6 Parse Tree Statistics : :: ::: :: :: :: :: ::: :: :: :: 28 12.7 Adjusting the Sizes of Ox's Data Structures : ::: :: :: :: 29 13 Example: An Integer Calculator 29 14 Example: A Binary Number Translator 31 15 Example: Translation from In x to Post x and Pre x 35 1 OVERVIEW OF USE 3 1 Overview of Use Lex and Yacc are p owerful and widely-used to ols for the automatic gen- eration of language recognizers. Lex accepts a set of user-written regular expressions and writes a C program that p erforms lexical analysis accord- ing to those expressions. Yacc translates user-written grammar rules into C source co de for a syntax analyzer. While they a ord \ho oks" for execution of hand-co ded C-language semantic actions, Lex and Yacc provide little other facility for automatic implementation of language semantics. Attributed parse trees are often used as data structures in evaluators for languages. Often the language implementer hand-crafts co de for building, traversing, and evaluating attributes of parse trees, and for parse-tree-related memory management. A Yacc sp eci cation de nes a context-free language and a mapping from the set of legal sentences to the set of parse trees, but co de for parse-tree management is not generated automatically by Yacc. 1 The Ox user sp eci es a language using the familiar languages of Lex and Yacc,ortakes an existing Lex/Yacc sp eci cation, and adds semantics to the language by augmenting the sp eci cation les with declarations and de nitions of typ ed attributes of parse-tree no des. That sp eci cation constitutes an attribute grammar, and from it Ox au- tomatically generates an evaluator written in Yacc, Lex, and C.For a given input, the evaluator builds a parse tree, determines an order of evaluation for attributes of the tree, and p erforms, for each attribute, the semantic action required to evaluate it. This parse tree is managed indep endently of any trees managed by hand-written C co de, but information maybemoved b etween the evaluator-managed tree and any global data structure. Additionally, the Ox user may easily sp ecify parse-tree traversals that are p erformed after evaluation of the tree's attributes and that refer to those attributes. Such traversals greatly simplify tasks such as co de generation and the gathering of compilation statistics. The language designer is freed from the tedious and error-prone details of writing co de for parse-tree management. Ox-generated evaluators use memory-management techniques that bring large time-eciency gains over 1 The name \Ox" originated as a homophone for an acronym for \An Attribute Gram- mar Compiling System". It was noticed later that every yak is an ox and that Ox gener- alizes the function of Yacc. 2 PRELIMINARY 4 hand-built evaluators that use the common technique of calling malloc once for each parse-tree no de. Also, Ox provides securityby testing the de nition for consistency and completeness, and the Ox-generated evaluator p erforms tests to ensure that a circular de nition has not prevented evaluation of attributes. Ox is a prepro cessor that accepts two or more les, and translates these into les suitable for input to Lex and Yacc. With few exceptions, all Lex- input/Yacc-input pairs of les that constitute recognizers or translators are legal inputs to Ox.Thus much existing software is amenable to mo di cation using Ox, and implementations that use Ox may b e converted stepwise by hand to \pure" Lex/Yacc implementations. This makes Ox well-suited to language designers, exp erimenters, and implementers already familiar with Lex, Yacc, and C. 2 Preliminary It is assumed that the reader is familiar with the use of Yacc [Johnson 75 ], Lex [Lesk 75], and C [KR 88 ]; Ox syntactic constructs are describ ed mainly as augmentations of the languages accepted by those to ols. Prior acquain- tance with the basic ideas of attribute grammars for instance, as found in [Waite 84 ] or [Aho 86 ] is helpful. An Ox input sp eci cation consists of at least two les: a syntactic sp ec- i cation which resembles a Yacc input sp eci cation and is called a Y- le that Ox translates into a Yacc input sp eci cation, and one or more lex- ical sp eci cations which resemble Lex input sp eci cations and are called L- les that Ox translates into Lex input sp eci cations. Usually there is ex- actly one L- le, but an evaluator that uses more than one scanner [Lesk 75] may b e constructed by submitting to Ox more than one L- le. This man- ual presents descriptions of the Ox-sp eci c constructs that may app ear in these les, as well as p ertinent underlying concepts. These constructs are illustrated mainly by using fragments of three examples of Ox input sp eci - cations, the complete texts of which app ear in sections 13, 14 and 15. Within Ox-sp eci c constructs, C-style comments may app ear anywhere whitespace may app ear. The global identi ers of Ox-generated C co de, like those generated by Yacc and Lex, are pre xed by yy, so the Ox user can avoid name con icts in the generated evaluator by abstaining from the use 3 ATTRIBUTE DECLARATIONS 5 of global identi ers that b egin with yy.
Load more

Recommended publications
  • Administering Unidata on UNIX Platforms
    C:\Program Files\Adobe\FrameMaker8\UniData 7.2\7.2rebranded\ADMINUNIX\ADMINUNIXTITLE.fm March 5, 2010 1:34 pm Beta Beta Beta Beta Beta Beta Beta Beta Beta Beta Beta Beta Beta Beta Beta Beta UniData Administering UniData on UNIX Platforms UDT-720-ADMU-1 C:\Program Files\Adobe\FrameMaker8\UniData 7.2\7.2rebranded\ADMINUNIX\ADMINUNIXTITLE.fm March 5, 2010 1:34 pm Beta Beta Beta Beta Beta Beta Beta Beta Beta Beta Beta Beta Beta Notices Edition Publication date: July, 2008 Book number: UDT-720-ADMU-1 Product version: UniData 7.2 Copyright © Rocket Software, Inc. 1988-2010. All Rights Reserved. Trademarks The following trademarks appear in this publication: Trademark Trademark Owner Rocket Software™ Rocket Software, Inc. Dynamic Connect® Rocket Software, Inc. RedBack® Rocket Software, Inc. SystemBuilder™ Rocket Software, Inc. UniData® Rocket Software, Inc. UniVerse™ Rocket Software, Inc. U2™ Rocket Software, Inc. U2.NET™ Rocket Software, Inc. U2 Web Development Environment™ Rocket Software, Inc. wIntegrate® Rocket Software, Inc. Microsoft® .NET Microsoft Corporation Microsoft® Office Excel®, Outlook®, Word Microsoft Corporation Windows® Microsoft Corporation Windows® 7 Microsoft Corporation Windows Vista® Microsoft Corporation Java™ and all Java-based trademarks and logos Sun Microsystems, Inc. UNIX® X/Open Company Limited ii SB/XA Getting Started The above trademarks are property of the specified companies in the United States, other countries, or both. All other products or services mentioned in this document may be covered by the trademarks, service marks, or product names as designated by the companies who own or market them. License agreement This software and the associated documentation are proprietary and confidential to Rocket Software, Inc., are furnished under license, and may be used and copied only in accordance with the terms of such license and with the inclusion of the copyright notice.
    [Show full text]
  • Oregon Statewide Payroll Application ‐ Paystub Pay and Leave Codes
    Oregon Statewide Payroll Application ‐ Paystub Pay and Leave Codes PAYSTUB PAY AND LEAVE CODES Pay Type Code Paystub Description Detail Description ABL OSPOA BUSINESS Leave used when conducting OSPOA union business by authorized individuals. Leave must be donated from employees within the bargaining unit. A donation/use maximum is established by contract. AD ADMIN LV Paid leave time granted to compensate for work performed outside normal work hours by Judicial Department employees who are ineligible for overtime. (Agency Policy) ALC ASST LGL DIF 5% Differential for Assistant Legal Counsel at Judicial Department. (PPDB code) ANA ALLW N/A PLN Code used to record taxable cash value of non-cash clothing allowance or other employee fringe benefit. (P050) ANC NRS CRED Nurses credentialing per CBA ASA APPELATE STF Judicial Department Appellate Judge differential. (PPDB code) AST ADDL STRAIGHTTIME Additional straight time hours worked within same period that employee recorded sick, holiday, or other regular paid leave hours. Refer to Statewide Policy or Collective Bargaining Agreement. Hours not used in leave and benefit calculations. AT AWARD TM TKN Paid leave for Judicial Department and Public Defense Service employees as years of service award. (Agency Policy) AW ASSUMED WAGES-UNPD Code used to record and track hours of volunteer non-employee workers. Does not VOL HR generate pay. (P050) BAV BP/AWRD VALU Code used to record the taxable cash value of a non-cash award or bonus granted through an agency recognition program. Not PERS subject. (P050 code) BBW BRDG/BM/WELDR Certified Bridge/Boom/Welder differential (PPDB code) BCD BRD CERT DIFF Board Certification Differential for Nurse Practitioners at the Oregon State Hospital of five percent (5%) for all Nurse Practitioners who hold a Board certification related to their assignment.
    [Show full text]
  • Chapter # 9 LEX and YACC
    Chapter # 9 LEX and YACC Dr. Shaukat Ali Department of Computer Science University of Peshawar Lex and Yacc Lex and yacc are a matched pair of tools. Lex breaks down files into sets of "tokens," roughly analogous to words. Yacc takes sets of tokens and assembles them into higher-level constructs, analogous to sentences. Lex's output is mostly designed to be fed into some kind of parser. Yacc is designed to work with the output of Lex. 2 Lex and Yacc Lex and yacc are tools for building programs. Their output is itself code – Which needs to be fed into a compiler – May be additional user code is added to use the code generated by lex and yacc 3 Lex : A lexical analyzer generator Lex is a program designed to generate scanners, also known as tokenizers, which recognize lexical patterns in text Lex is an acronym that stands for "lexical analyzer generator.“ The main purpose is to facilitate lexical analysis The processing of character sequences in source code to produce tokens for use as input to other programs such as parsers Another tool for lexical analyzer generation is Flex 4 Lex : A lexical analyzer generator lex.lex is an a input file written in a language which describes the generation of lexical analyzer. The lex compiler transforms lex.l to a C program known as lex.yy.c. lex.yy.c is compiled by the C compiler to a file called a.out. The output of C compiler is the working lexical analyzer which takes stream of input characters and produces a stream of tokens.
    [Show full text]
  • Text Editing in UNIX: an Introduction to Vi and Editing
    Text Editing in UNIX A short introduction to vi, pico, and gedit Copyright 20062009 Stewart Weiss About UNIX editors There are two types of text editors in UNIX: those that run in terminal windows, called text mode editors, and those that are graphical, with menus and mouse pointers. The latter require a windowing system, usually X Windows, to run. If you are remotely logged into UNIX, say through SSH, then you should use a text mode editor. It is possible to use a graphical editor, but it will be much slower to use. I will explain more about that later. 2 CSci 132 Practical UNIX with Perl Text mode editors The three text mode editors of choice in UNIX are vi, emacs, and pico (really nano, to be explained later.) vi is the original editor; it is very fast, easy to use, and available on virtually every UNIX system. The vi commands are the same as those of the sed filter as well as several other common UNIX tools. emacs is a very powerful editor, but it takes more effort to learn how to use it. pico is the easiest editor to learn, and the least powerful. pico was part of the Pine email client; nano is a clone of pico. 3 CSci 132 Practical UNIX with Perl What these slides contain These slides concentrate on vi because it is very fast and always available. Although the set of commands is very cryptic, by learning a small subset of the commands, you can edit text very quickly. What follows is an outline of the basic concepts that define vi.
    [Show full text]
  • Small Group Instructional Diagnosis: Final Report
    DOCUMENT RESUME JC 820 333 , ED 217 954 AUTHOR Clark, D. Joseph; Redmond, Mark V. TITLE Small Group Instructional Diagnosis: Final Report. INSTITUTION Washington Univ., Seattle. Dept. of Biology c Education. ., 'SPONS AGENCY Fund for the Improwsent of Postsecondary Education . (ED), Washington, D.C. , PUB DATE [82] NOTE 21p.; Appendices mentioned in the report are not _ included. EDRS PRICE , 401/PC01 Plus Postage. DESCRIPTORS *Course Evaluation; *Evaluation Methods; *Instructional Improvement; Postsecondary Education; *Student Evaluation of Teacher Performance;- tudent , Reaction; *Teacher Attitudes; Teacher Workshop IDENTIFIERS *Small group Instructional Diagnosis, ABSTRACT- A procedure for student evaluation andfeedback on faculty instruction was developed at the University of Washington. The system involved the use of,faculty members as facilitatorsin ,conducting Small Group Instructional Diagnosis (SGID) to generate student feedback to instructors about- the courses' strengths, areas needing improvement, and suggestions for bringing about these improvements. The SGID.procedure involves a number of steps:contact between the facilitator and instructor; classroomintervention to ascertain student opinions; a feedback session between facilitator and instructor; instructor. review of the SGID with the class;and ,a follow-up session between the facilitator and instructor.Following the development of the SGID process, handouts andvideotapes were produced to explain the procedure and the SGID technique was demonstrated in over 130 classes
    [Show full text]
  • Project1: Build a Small Scanner/Parser
    Project1: Build A Small Scanner/Parser Introducing Lex, Yacc, and POET cs5363 1 Project1: Building A Scanner/Parser Parse a subset of the C language Support two types of atomic values: int float Support one type of compound values: arrays Support a basic set of language concepts Variable declarations (int, float, and array variables) Expressions (arithmetic and boolean operations) Statements (assignments, conditionals, and loops) You can choose a different but equivalent language Need to make your own test cases Options of implementation (links available at class web site) Manual in C/C++/Java (or whatever other lang.) Lex and Yacc (together with C/C++) POET: a scripting compiler writing language Or any other approach you choose --- must document how to download/use any tools involved cs5363 2 This is just starting… There will be two other sub-projects Type checking Check the types of expressions in the input program Optimization/analysis/translation Do something with the input code, output the result The starting project is important because it determines which language you can use for the other projects Lex+Yacc ===> can work only with C/C++ POET ==> work with POET Manual ==> stick to whatever language you pick This class: introduce Lex/Yacc/POET to you cs5363 3 Using Lex to build scanners lex.yy.c MyLex.l lex/flex lex.yy.c a.out gcc/cc Input stream a.out tokens Write a lex specification Save it in a file (MyLex.l) Compile the lex specification file by invoking lex/flex lex MyLex.l A lex.yy.c file is generated
    [Show full text]
  • Yacc a Tool for Syntactic Analysis
    1 Yacc a tool for Syntactic Analysis CS 315 – Programming Languages Pinar Duygulu Bilkent University CS315 Programming Languages © Pinar Duygulu Lex and Yacc 2 1) Lexical Analysis: Lexical analyzer: scans the input stream and converts sequences of characters into tokens. Lex is a tool for writing lexical analyzers. 2) Syntactic Analysis (Parsing): Parser: reads tokens and assembles them into language constructs using the grammar rules of the language. Yacc is a tool for constructing parsers. Yet Another Compiler to Compiler Reads a specification file that codifies the grammar of a language and generates a parsing routine CS315 Programming Languages © Pinar Duygulu 3 Yacc • Yacc specification describes a Context Free Grammar (CFG), that can be used to generate a parser. Elements of a CFG: 1. Terminals: tokens and literal characters, 2. Variables (nonterminals): syntactical elements, 3. Production rules, and 4. Start rule. CS315 Programming Languages © Pinar Duygulu 4 Yacc Format of a production rule: symbol: definition {action} ; Example: A → Bc is written in yacc as a: b 'c'; CS315 Programming Languages © Pinar Duygulu 5 Yacc Format of a yacc specification file: declarations %% grammar rules and associated actions %% C programs CS315 Programming Languages © Pinar Duygulu 6 Declarations To define tokens and their characteristics %token: declare names of tokens %left: define left-associative operators %right: define right-associative operators %nonassoc: define operators that may not associate with themselves %type: declare the type of variables %union: declare multiple data types for semantic values %start: declare the start symbol (default is the first variable in rules) %prec: assign precedence to a rule %{ C declarations directly copied to the resulting C program %} (E.g., variables, types, macros…) CS315 Programming Languages © Pinar Duygulu 7 A simple yacc specification to accept L={ anbn | n>1}.
    [Show full text]
  • Binpac: a Yacc for Writing Application Protocol Parsers
    binpac: A yacc for Writing Application Protocol Parsers Ruoming Pang∗ Vern Paxson Google, Inc. International Computer Science Institute and New York, NY, USA Lawrence Berkeley National Laboratory [email protected] Berkeley, CA, USA [email protected] Robin Sommer Larry Peterson International Computer Science Institute Princeton University Berkeley, CA, USA Princeton, NJ, USA [email protected] [email protected] ABSTRACT Similarly, studies of Email traffic [21, 46], peer-to-peer applica- A key step in the semantic analysis of network traffic is to parse the tions [37], online gaming, and Internet attacks [29] require under- traffic stream according to the high-level protocols it contains. This standing application-level traffic semantics. However, it is tedious, process transforms raw bytes into structured, typed, and semanti- error-prone, and sometimes prohibitively time-consuming to build cally meaningful data fields that provide a high-level representation application-level analysis tools from scratch, due to the complexity of the traffic. However, constructing protocol parsers by hand is a of dealing with low-level traffic data. tedious and error-prone affair due to the complexity and sheer num- We can significantly simplify the process if we can leverage a ber of application protocols. common platform for various kinds of application-level traffic anal- This paper presents binpac, a declarative language and com- ysis. A key element of such a platform is application-protocol piler designed to simplify the task of constructing robust and effi- parsers that translate packet streams into high-level representations cient semantic analyzers for complex network protocols. We dis- of the traffic, on top of which we can then use measurement scripts cuss the design of the binpac language and a range of issues that manipulate semantically meaningful data elements such as in generating efficient parsers from high-level specifications.
    [Show full text]
  • An Attribute- Grammar Compiling System Based on Yacc, Lex, and C Kurt M
    View metadata, citation and similar papers at core.ac.uk brought to you by CORE provided by Digital Repository @ Iowa State University Computer Science Technical Reports Computer Science 12-1992 Design, Implementation, Use, and Evaluation of Ox: An Attribute- Grammar Compiling System based on Yacc, Lex, and C Kurt M. Bischoff Iowa State University Follow this and additional works at: http://lib.dr.iastate.edu/cs_techreports Part of the Programming Languages and Compilers Commons Recommended Citation Bischoff, Kurt M., "Design, Implementation, Use, and Evaluation of Ox: An Attribute- Grammar Compiling System based on Yacc, Lex, and C" (1992). Computer Science Technical Reports. 23. http://lib.dr.iastate.edu/cs_techreports/23 This Article is brought to you for free and open access by the Computer Science at Iowa State University Digital Repository. It has been accepted for inclusion in Computer Science Technical Reports by an authorized administrator of Iowa State University Digital Repository. For more information, please contact [email protected]. Design, Implementation, Use, and Evaluation of Ox: An Attribute- Grammar Compiling System based on Yacc, Lex, and C Abstract Ox generalizes the function of Yacc in the way that attribute grammars generalize context-free grammars. Ordinary Yacc and Lex specifications may be augmented with definitions of synthesized and inherited attributes written in C syntax. From these specifications, Ox generates a program that builds and decorates attributed parse trees. Ox accepts a most general class of attribute grammars. The user may specify postdecoration traversals for easy ordering of side effects such as code generation. Ox handles the tedious and error-prone details of writing code for parse-tree management, so its use eases problems of security and maintainability associated with that aspect of translator development.
    [Show full text]
  • A Brief Introduction to Unix-2019-AMS
    A Brief Introduction to Linux/Unix – AMS 2019 Pete Pokrandt UW-Madison AOS Systems Administrator [email protected] Twitter @PTH1 Brief Intro to Linux/Unix o Brief History of Unix o Basics of a Unix session o The Unix File System o Working with Files and Directories o Your Environment o Common Commands Brief Intro to Unix (contd) o Compilers, Email, Text processing o Image Processing o The vi editor History of Unix o Created in 1969 by Kenneth Thompson and Dennis Ritchie at AT&T o Revised in-house until first public release 1977 o 1977 – UC-Berkeley – Berkeley Software Distribution (BSD) o 1983 – Sun Workstations produced a Unix Workstation o AT&T unix -> System V History of Unix o Today – two main variants, but blended o System V (Sun Solaris, SGI, Dec OSF1, AIX, linux) o BSD (Old SunOS, linux, Mac OSX/MacOS) History of Unix o It’s been around for a long time o It was written by computer programmers for computer programmers o Case sensitive, mostly lowercase abbreviations Basics of a Unix Login Session o The Shell – the command line interface, where you enter commands, etc n Some common shells Bourne Shell (sh) C Shell (csh) TC Shell (tcsh) Korn Shell (ksh) Bourne Again Shell (bash) [OSX terminal] Basics of a Unix Login Session o Features provided by the shell n Create an environment that meets your needs n Write shell scripts (batch files) n Define command aliases n Manipulate command history n Automatically complete the command line (tab) n Edit the command line (arrow keys in tcsh) Basics of a Unix Login Session o Logging in to a unix
    [Show full text]
  • UNIX (Solaris/Linux) Quick Reference Card Logging in Directory Commands at the Login: Prompt, Enter Your Username
    UNIX (Solaris/Linux) QUICK REFERENCE CARD Logging In Directory Commands At the Login: prompt, enter your username. At the Password: prompt, enter ls Lists files in current directory your system password. Linux is case-sensitive, so enter upper and lower case ls -l Long listing of files letters as required for your username, password and commands. ls -a List all files, including hidden files ls -lat Long listing of all files sorted by last Exiting or Logging Out modification time. ls wcp List all files matching the wildcard Enter logout and press <Enter> or type <Ctrl>-D. pattern Changing your Password ls dn List files in the directory dn tree List files in tree format Type passwd at the command prompt. Type in your old password, then your new cd dn Change current directory to dn password, then re-enter your new password for verification. If the new password cd pub Changes to subdirectory “pub” is verified, your password will be changed. Many systems age passwords; this cd .. Changes to next higher level directory forces users to change their passwords at predetermined intervals. (previous directory) cd / Changes to the root directory Changing your MS Network Password cd Changes to the users home directory cd /usr/xx Changes to the subdirectory “xx” in the Some servers maintain a second password exclusively for use with Microsoft windows directory “usr” networking, allowing you to mount your home directory as a Network Drive. mkdir dn Makes a new directory named dn Type smbpasswd at the command prompt. Type in your old SMB passwword, rmdir dn Removes the directory dn (the then your new password, then re-enter your new password for verification.
    [Show full text]
  • Lex and Yacc
    Lex and Yacc A Quick Tour HW8–Use Lex/Yacc to Turn this: Into this: <P> Here's a list: Here's a list: * This is item one of a list <UL> * This is item two. Lists should be <LI> This is item one of a list indented four spaces, with each item <LI>This is item two. Lists should be marked by a "*" two spaces left of indented four spaces, with each item four-space margin. Lists may contain marked by a "*" two spaces left of four- nested lists, like this: space margin. Lists may contain * Hi, I'm item one of an inner list. nested lists, like this:<UL><LI> Hi, I'm * Me two. item one of an inner list. <LI>Me two. * Item 3, inner. <LI> Item 3, inner. </UL><LI> Item 3, * Item 3, outer list. outer list.</UL> This is outside both lists; should be back This is outside both lists; should be to no indent. back to no indent. <P><P> Final suggestions: Final suggestions 2 if myVar == 6.02e23**2 then f( .. ! char stream LEX token stream if myVar == 6.02e23**2 then f( ! tokenstream YACC parse tree if-stmt == fun call var ** Arg 1 Arg 2 float-lit int-lit . ! 3 Lex / Yacc History Origin – early 1970’s at Bell Labs Many versions & many similar tools Lex, flex, jflex, posix, … Yacc, bison, byacc, CUP, posix, … Targets C, C++, C#, Python, Ruby, ML, … We’ll use jflex & byacc/j, targeting java (but for simplicity, I usually just say lex/yacc) 4 Uses “Front end” of many real compilers E.g., gcc “Little languages”: Many special purpose utilities evolve some clumsy, ad hoc, syntax Often easier, simpler, cleaner and more flexible to use lex/yacc or similar tools from the start 5 Lex: A Lexical Analyzer Generator Input: Regular exprs defining "tokens" my.flex Fragments of declarations & code Output: jflex A java program “yylex.java” Use: yylex.java Compile & link with your main() Calls to yylex() read chars & return successive tokens.
    [Show full text]