DOCSLIB.ORG

UNIX Version 7 Volume 2A

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
UNIX Version 7 Volume 2A UNIXTM TIME-SHARING SYSTEM: UNIX PROGRAMMER'S MANUAL Seventh Edition, Volume 2A January, 1979 Bell Telephone Laboratories, Incorporated Murray Hill, New Jersey UNIX Programmer's Manual Volume 2 Ð Supplementary Documents Seventh Edition January 10, 1979 This volume contains documents which supplement the information contained in Volume 1 of The UNIX² Programmer's Manual. The documents here are grouped roughly into the areas of basics, editing, language tools, document preparation, and system maintenance. Further general information may be found in the Bell System Technical Journal special issue on UNIX, July-August, 1978. Many of the documents cited within this volume as Bell Laboratories internal memoranda or Com- puting Science Technical Reports (CSTR) are also contained here. These documents contain occasional localisms, typically references to other operating systems like GCOS and IBM. In all cases, such references may be safely ignored by UNIX users. General Works 1. 7th Edition UNIX Ð Summary. A concise summary of the facilities available on UNIX. 2. The UNIX Time-Sharing System. D. M. Ritchie and K. Thompson. The original UNIX paper, reprinted from CACM. Getting Started 3. UNIX for Beginners Ð Second Edition. B. W. Kernighan. An introduction to the most basic use of the system. 4. A Tutorial Introduction to the UNIX Text Editor. B. W. Kernighan. An easy way to get started with the editor. 5. Advanced Editing on UNIX. B. W. Kernighan. The next step. 6. An Introduction to the UNIX Shell. S. R. Bourne. An introduction to the capabilities of the command interpreter, the shell. 7. Learn Ð Computer Aided Instruction on UNIX. M. E. Lesk and B. W. Kernighan. Describes a computer-aided instruction program that walks new users through the basics of ®les, the editor, and document preparation software. Document Preparation 8. Typing Documents on the UNIX System. M. E. Lesk. Describes the basic use of the formatting tools. Also describes ``± ms'', a standardized package of formatting requests that can be used to lay out most documents (including those in this volume). __________________ ²UNIX is a Trademark of Bell Laboratories. - 2 - 9. A System for Typesetting Mathematics. B. W. Kernighan and L. L. Cherry. Describes EQN. an easy-to-learn language for doing high-quality mathematical typesetting, 10. TBL Ð A Program to Format Tables. M. E. Lesk. A program to permit easy speci®cation of tabular material for typesetting. Again, easy to learn and use. 11. Some Applications of Inverted Indexes on the UNIX System. M. E. Lesk. Describes, among other things, the program REFER which ®lls in bibliographic citations from a data base automatically. 12. NROFF/TROFF User's Manual. J. F. Ossanna. The basic formatting program. 13. A TROFF Tutorial. B. W. Kernighan. An introduction to TROFF for those who really want to know such things. Programming 14. The C Programming Language Ð Reference Manual. D. M. Ritchie. Of®cial statement of the syntax and semantics of C. Should be supplemented by The C Programming Language, B. W. Kernighan and D. M. Ritchie, Prentice-Hall, 1978, which contains a tutorial introduction and many examples. 15. Lint, A C Program Checker. S. C. Johnson. Checks C programs for syntax errors, type violations, portability problems, and a variety of probable errors. 16. Make Ð A Program for Maintaining Computer Programs. S. I. Feldman. Indispensable tool for making sure that large programs are properly compiled with minimal effort. 17. UNIX Programming. B. W. Kernighan and D. M. Ritchie. Describes the programming interface to the operating system and the standard I/O library. 18. A Tutorial Introduction to ADB. J. F. Maranzano and S. R. Bourne. How to use the ADB debugger. Supporting Tools and Languages 19. YACC: Yet Another Compiler-Compiler. S. C. Johnson. Converts a BNF speci®cation of a language and semantic actions written in C into a com- piler for the language. 20. LEX Ð A Lexical Analyzer Generator. M. E. Lesk and E. Schmidt. Creates a recognizer for a set of regular expressions; each regular expression can be fol- lowed by arbitrary C code which will be executed when the regular expression is found. 21. A Portable Fortran 77 Compiler. S. I. Feldman and P. J. Weinberger. The ®rst Fortran 77 compiler, and still one of the best. 22. Ratfor Ð A Preprocessor for a Rational Fortran. B. W. Kernighan. Converts a Fortran with C-like control structures and cosmetics into real, ugly Fortran. 23. The M4 Macro Processor. B. W. Kernighan and D. M. Ritchie. M4 is a macro processor useful as a front end for C, Ratfor, Cobol, and in its own right. 24. SED Ð A Non-interactive Text Editor. L. E. McMahon. A variant of the editor for processing large inputs. 25. AWK Ð A Pattern Scanning and Processing Language. A. V. Aho, B. W. Kernighan and P. J. Weinberger. Makes it easy to specify many data transformation and selection operations. - 3 - 26. DC Ð An Interactive Desk Calculator. R. H. Morris and L. L. Cherry. A super HP calculator, if you don't need ¯oating point. 27. BC Ð An Arbitrary Precision Desk-Calculator Language. L. L. Cherry and R. H. Morris. A front end for DC that provides in®x notation, control ¯ow, and built-in functions. 28. UNIX Assembler Reference Manual. D. M. Ritchie. The ultimate dead language. Implementation, Maintenance, and Miscellaneous 29. Setting Up UNIX Ð Seventh Edition. C. B. Haley and D. M. Ritchie. How to con®gure and get your system running. 30. Regenerating System Software. C. B. Haley and D. M. Ritchie. What do do when you have to change things. 31. UNIX Implementation. K. Thompson. How the system actually works inside. 32. The UNIX I/O System. D. M. Ritchie. How the I/O system really works. 33. A Tour Through the UNIX C Compiler. D. M. Ritchie. How the PDP-11 compiler works inside. 34. A Tour Through the Portable C Compiler. S. C. Johnson. How the portable C compiler works inside. 35. A Dial-Up Network of UNIX Systems. D. A. Nowitz and M. E. Lesk. Describes UUCP, a program for communicating ®les between UNIX systems. 36. UUCP Implementation Description. D. A. Nowitz. How UUCP works, and how to administer it. 37. On the Security of UNIX. D. M. Ritchie. Hints on how to break UNIX, and how to avoid doing so. 38. Password Security: A Case History. R. H. Morris and K. Thompson. How the bad guys used to be able to break the password algorithm, and why they can't now, at least not so easily. 7th Edition UNIX Ð Summary September 6, 1978 Bell Laboratories Murray Hill, New Jersey 07974 A. What's new: highlights of the 7th edition UNIX² System Aimed at larger systems. Devices are addressable to 231 bytes, ®les to 230 bytes. 128K memory (separate instruction and data space) is needed for some utilities. Portability. Code of the operating system and most utilities has been extensively revised to minimize its dependence on particular hardware. Fortran 77. F77 compiler for the new standard language is compatible with C at the object level. A Fortran structurer, STRUCT, converts old, ugly Fortran into RATFOR, a structured dialect usable with F77. Shell. Completely new SH program supports string variables, trap handling, structured programming, user pro®les, settable search path, multilevel ®le name generation, etc. Document preparation. TROFF phototypesetter utility is standard. NROFF (for terminals) is now highly compatible with TROFF. MS macro package provides canned commands for many common for- matting and layout situations. TBL provides an easy to learn language for preparing complicated tabular material. REFER ®lls in bibliographic citations from a data base. UNIX-to-UNIX ®le copy. UUCP performs spooled ®le transfers between any two machines. Data processing. SED stream editor does multiple editing functions in parallel on a data stream of inde®nite length. AWK report generator does free-®eld pattern selection and arithmetic operations. Program development. MAKE controls re-creation of complicated software, arranging for minimal recompilation. Debugging. ADB does postmortem and breakpoint debugging, handles separate instruction and data spaces, ¯oating point, etc. C language. The language now supports de®nable data types, generalized initialization, block structure, long integers, unions, explicit type conversions. The LINT veri®er does strong type checking and detec- tion of probable errors and portability problems even across separately compiled functions. Lexical analyzer generator. LEX converts speci®cation of regular expressions and semantic actions into a recognizing subroutine. Analogous to YACC. Graphics. Simple graph-drawing utility, graphic subroutines, and generalized plotting ®lters adapted to various devices are now standard. Standard input-output package. Highly ef®cient buffered stream I/O is integrated with formatted input and output. Other. The operating system and utilities have been enhanced and freed of restrictions in many other ways too numerous to relate. __________________ ² UNIX is a Trademark of Bell Laboratories. - 2 - B. Hardware The 7th edition UNIX operating system runs on a DEC PDP-11/45 or 11/70* with at least the fol- lowing equipment: 128K to 2M words of managed memory; parity not used. disk: RP03, RP04, RP06, RK05 (more than 1 RK05) or equivalent. console typewriter. clock: KW11-L or KW11-P. The following equipment is strongly recommended: communications controller such as DL11 or DH11. full duplex 96-character ASCII terminals. 9-track tape or extra disk for system backup. The system is normally distributed on 9-track tape. The minimum memory and disk space speci®ed is enough to run and maintain UNIX. More will be needed to keep all source on line, or to handle a large number of users, big data bases, diversi®ed complements of devices, or large programs.
Load more

Recommended publications
  • UNIX and Computer Science Spreading UNIX Around the World: by Ronda Hauben an Interview with John Lions
    Winter/Spring 1994 Celebrating 25 Years of UNIX Volume 6 No 1 "I believe all significant software movements start at the grassroots level. UNIX, after all, was not developed by the President of AT&T." Kouichi Kishida, UNIX Review, Feb., 1987 UNIX and Computer Science Spreading UNIX Around the World: by Ronda Hauben An Interview with John Lions [Editor's Note: This year, 1994, is the 25th anniversary of the [Editor's Note: Looking through some magazines in a local invention of UNIX in 1969 at Bell Labs. The following is university library, I came upon back issues of UNIX Review from a "Work In Progress" introduced at the USENIX from the mid 1980's. In these issues were articles by or inter- Summer 1993 Conference in Cincinnati, Ohio. This article is views with several of the pioneers who developed UNIX. As intended as a contribution to a discussion about the sig- part of my research for a paper about the history and devel- nificance of the UNIX breakthrough and the lessons to be opment of the early days of UNIX, I felt it would be helpful learned from it for making the next step forward.] to be able to ask some of these pioneers additional questions The Multics collaboration (1964-1968) had been created to based on the events and developments described in the UNIX "show that general-purpose, multiuser, timesharing systems Review Interviews. were viable." Based on the results of research gained at MIT Following is an interview conducted via E-mail with John using the MIT Compatible Time-Sharing System (CTSS), Lions, who wrote A Commentary on the UNIX Operating AT&T and GE agreed to work with MIT to build a "new System describing Version 6 UNIX to accompany the "UNIX hardware, a new operating system, a new file system, and a Operating System Source Code Level 6" for the students in new user interface." Though the project proceeded slowly his operating systems class at the University of New South and it took years to develop Multics, Doug Comer, a Profes- Wales in Australia.
    [Show full text]
  • ROADS and BRIDGES: the UNSEEN LABOR BEHIND OUR DIGITAL INFRASTRUCTURE Preface
    Roads and Bridges:The Unseen Labor Behind Our Digital Infrastructure WRITTEN BY Nadia Eghbal 2 Open up your phone. Your social media, your news, your medical records, your bank: they are all using free and public code. Contents 3 Table of Contents 4 Preface 58 Challenges Facing Digital Infrastructure 5 Foreword 59 Open source’s complicated relationship with money 8 Executive Summary 66 Why digital infrastructure support 11 Introduction problems are accelerating 77 The hidden costs of ignoring infrastructure 18 History and Background of Digital Infrastructure 89 Sustaining Digital Infrastructure 19 How software gets built 90 Business models for digital infrastructure 23 How not charging for software transformed society 97 Finding a sponsor or donor for an infrastructure project 29 A brief history of free and public software and the people who made it 106 Why is it so hard to fund these projects? 109 Institutional efforts to support digital infrastructure 37 How The Current System Works 38 What is digital infrastructure, and how 124 Opportunities Ahead does it get built? 125 Developing effective support strategies 46 How are digital infrastructure projects managed and supported? 127 Priming the landscape 136 The crossroads we face 53 Why do people keep contributing to these projects, when they’re not getting paid for it? 139 Appendix 140 Glossary 142 Acknowledgements ROADS AND BRIDGES: THE UNSEEN LABOR BEHIND OUR DIGITAL INFRASTRUCTURE Preface Our modern society—everything from hospitals to stock markets to newspapers to social media—runs on software. But take a closer look, and you’ll find that the tools we use to build software are buckling under demand.
    [Show full text]
  • An Automated Binary Security Update System for Freebsd
    An Automated Binary Security Update System for FreeBSD Colin Percival Computing Lab, Oxford University [email protected] Abstract that a large number of people find the task of applying security patches and rebuilding affected programs to be difficult and/or confusing. Given that releases are on av- With the present trend towards increased reliance upon erage several months – and several security holes – old computer systems, the provision and prompt application by the time they are installed, the possibility arises that of security patches is becoming vital. Developers of all a new user will find his system compromised before he operating systems must generally be applauded for their has a chance to bring it up to date. success in this area; systems administrators, however, are often found lacking. Furthermore, there are some circumstances where build- ing from source is undesirable. Some embedded sys- Anecdotal evidence suggests that for FreeBSD much of tems might lack sufficient disk space to store the entire the difficulty arises out of the need to recompile from the source and object trees; some system administrators re- source code after applying security patches. Many peo- move part or all of the build toolchain in an (arguably ple, after spending years using closed-source point-and- misguided) attempt to thwart any attempt to build a click operating systems, find the concept of recompiling rootkit; and the purveyors of application-specific ‘toast- software to be entirely foreign, and even veteran users ers’ might very likely wish to keep the complexity of of open source software are often less than prompt about building from source entirely hidden from their users.
    [Show full text]
  • Wait, I Don't Want to Be the Linux Administrator for SAS VA
    SESUG Paper 88-2017 Wait, I don’t want to be the Linux Administrator for SAS VA Jonathan Boase; Zencos Consulting ABSTRACT Whether you are a new SAS administrator or switching to a Linux environment, you have a complex mission. This job becomes even more formidable when you are working with a system like SAS Visual Analytics that requires multiple users loading data daily. Eventually a user will have data issues or create a disruption that causes the system to malfunction. When that happens, what do you do next? In this paper, we will go through the basics of a SAS Visual Analytics Linux environment and how to troubleshoot the system when issues arise. INTRODUCTION Many companies choose to implement SAS Visual Analytics in a Linux environment. With a distributed deployment, it’s the only choice but many chose this operating system because it reduces operating costs. If you are the newly chosen SAS platform administrator, you might be more versed in a Windows environment and feel intimidated by Linux. This paper introduces using basic Linux commands and methods for troubleshooting a SAS Visual Analytics environment. The paper assumes that SAS Visual Analytics is installed on a SAS 9.4 platform for Linux and that the reader has some familiarity with other operating systems, such as Windows. PLATFORM ADMINISTRATION 101 SAS platform administrators work with three main product areas. Each area provides a different functionality based on the task the administrator needs to perform. The following figure defines each area and provides a general overview of its purpose. Figure 1 Platform Administrator Tools Operating System SAS Management SAS Environment •Contains installed Console Manager software •Access and manage the •Monitor the •Contains logs used for metadata environment troubleshooting •Control database •Configure custom alerts •Administer host system connections users •Manage user accounts •Manage the LASR server With any operating system, there is always a lot to learn.
    [Show full text]
  • Reasoning About Programs Need: Definition of Works/Correct: a Specification (And Bugs) but Programs Fail All the Time
    Good programs, broken programs? Goal: program works (does not fail) Reasoning about Programs Need: definition of works/correct: a specification (and bugs) But programs fail all the time. Why? A brief interlude on 1. Misuse of your code: caller did not meet assumptions specifications, assertions, and debugging 2. Errors in your code: mistake causes wrong computation 3. Unpredictable external problems: • Out of memory, missing file, network down, … • Plan for these problems, fail gracefully. 4. Wrong or ambiguous specification, implemented correctly Largely based on material from University of Washington CSE 331 A Bug's Life, ca. 1947 A Bug's Life Defect: a mistake in the code Think 10 per 1000 lines of industry code. We're human. -- Grace Hopper Error: incorrect computation Because of defect, but not guaranteed to be visible Failure: observable error -- program violates its specification Crash, wrong output, unresponsive, corrupt data, etc. Time / code distance between stages varies: • tiny (<second to minutes / one line of code) • or enormous (years to decades to never / millons of lines of code) "How to build correct code" Testing 1. Design and Verify Make correctness more likely or provable from the start. • Can show that a program has an error. 2. Program Defensively • Can show a point where an error causes a failure. Plan for defects and errors. • Cannot show the error that caused the failure. • make testing more likely to reveal errors as failures • Cannot show the defect that caused the error. • make debugging failures easier 3. Test and Validate Try to cause failures. • Can improve confidence that the sorts of errors/failures • provide evidence of defects/errors targeted by the tests are less likely in programs similar • or increase confidence of their absence to the tests.
    [Show full text]
  • To Type Or Not to Type: Quantifying Detectable Bugs in Javascript
    To Type or Not to Type: Quantifying Detectable Bugs in JavaScript Zheng Gao Christian Bird Earl T. Barr University College London Microsoft Research University College London London, UK Redmond, USA London, UK [email protected] [email protected] [email protected] Abstract—JavaScript is growing explosively and is now used in to invest in static type systems for JavaScript: first Google large mature projects even outside the web domain. JavaScript is released Closure1, then Microsoft published TypeScript2, and also a dynamically typed language for which static type systems, most recently Facebook announced Flow3. What impact do notably Facebook’s Flow and Microsoft’s TypeScript, have been written. What benefits do these static type systems provide? these static type systems have on code quality? More concretely, Leveraging JavaScript project histories, we select a fixed bug how many bugs could they have reported to developers? and check out the code just prior to the fix. We manually add The fact that long-running JavaScript projects have extensive type annotations to the buggy code and test whether Flow and version histories, coupled with the existence of static type TypeScript report an error on the buggy code, thereby possibly systems that support gradual typing and can be applied to prompting a developer to fix the bug before its public release. We then report the proportion of bugs on which these type systems JavaScript programs with few modifications, enables us to reported an error. under-approximately quantify the beneficial impact of static Evaluating static type systems against public bugs, which type systems on code quality.
    [Show full text]
  • GNU Grep: Print Lines That Match Patterns Version 3.7, 8 August 2021
    GNU Grep: Print lines that match patterns version 3.7, 8 August 2021 Alain Magloire et al. This manual is for grep, a pattern matching engine. Copyright c 1999{2002, 2005, 2008{2021 Free Software Foundation, Inc. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.3 or any later version published by the Free Software Foundation; with no Invariant Sections, with no Front-Cover Texts, and with no Back-Cover Texts. A copy of the license is included in the section entitled \GNU Free Documentation License". i Table of Contents 1 Introduction ::::::::::::::::::::::::::::::::::::: 1 2 Invoking grep :::::::::::::::::::::::::::::::::::: 2 2.1 Command-line Options ::::::::::::::::::::::::::::::::::::::::: 2 2.1.1 Generic Program Information :::::::::::::::::::::::::::::: 2 2.1.2 Matching Control :::::::::::::::::::::::::::::::::::::::::: 2 2.1.3 General Output Control ::::::::::::::::::::::::::::::::::: 3 2.1.4 Output Line Prefix Control :::::::::::::::::::::::::::::::: 5 2.1.5 Context Line Control :::::::::::::::::::::::::::::::::::::: 6 2.1.6 File and Directory Selection:::::::::::::::::::::::::::::::: 7 2.1.7 Other Options ::::::::::::::::::::::::::::::::::::::::::::: 9 2.2 Environment Variables:::::::::::::::::::::::::::::::::::::::::: 9 2.3 Exit Status :::::::::::::::::::::::::::::::::::::::::::::::::::: 12 2.4 grep Programs :::::::::::::::::::::::::::::::::::::::::::::::: 13 3 Regular Expressions ::::::::::::::::::::::::::: 14 3.1 Fundamental Structure ::::::::::::::::::::::::::::::::::::::::
    [Show full text]
  • Drilling Network Stacks with Packetdrill
    Drilling Network Stacks with packetdrill NEAL CARDWELL AND BARATH RAGHAVAN Neal Cardwell received an M.S. esting and troubleshooting network protocols and stacks can be in Computer Science from the painstaking. To ease this process, our team built packetdrill, a tool University of Washington, with that lets you write precise scripts to test entire network stacks, from research focused on TCP and T the system call layer down to the NIC hardware. packetdrill scripts use a Web performance. He joined familiar syntax and run in seconds, making them easy to use during develop- Google in 2002. Since then he has worked on networking software for google.com, the ment, debugging, and regression testing, and for learning and investigation. Googlebot web crawler, the network stack in Have you ever had the experience of staring at a long network trace, trying to figure out what the Linux kernel, and TCP performance and on earth went wrong? When a network protocol is not working right, how might you find the testing. [email protected] problem and fix it? Although tools like tcpdump allow us to peek under the hood, and tools like netperf help measure networks end-to-end, reproducing behavior is still hard, and know- Barath Raghavan received a ing when an issue has been fixed is even harder. Ph.D. in Computer Science from UC San Diego and a B.S. from These are the exact problems that our team used to encounter on a regular basis during UC Berkeley. He joined Google kernel network stack development. Here we describe packetdrill, which we built to enable in 2012 and was previously a scriptable network stack testing.
    [Show full text]
  • “Linux at the Command Line” Don Johnson of BU IS&T  We’Ll Start with a Sign in Sheet
    “Linux at the Command Line” Don Johnson of BU IS&T We’ll start with a sign in sheet. We’ll end with a class evaluation. We’ll cover as much as we can in the time allowed; if we don’t cover everything, you’ll pick it up as you continue working with Linux. This is a hands-on, lab class; ask questions at any time. Commands for you to type are in BOLD The Most Common O/S Used By BU Researchers When Working on a Server or Computer Cluster Linux is a Unix clone begun in 1991 and written from scratch by Linus Torvalds with assistance from a loosely-knit team of hackers across the Net. 64% of the world’s servers run some variant of Unix or Linux. The Android phone and the Kindle run Linux. a set of small Linux is an O/S core programs written by written by Linus Richard Stallman and Torvalds and others others. They are the AND GNU utilities. http://www.gnu.org/ Network: ssh, scp Shells: BASH, TCSH, clear, history, chsh, echo, set, setenv, xargs System Information: w, whoami, man, info, which, free, echo, date, cal, df, free Command Information: man, info Symbols: |, >, >>, <, ;, ~, ., .. Filters: grep, egrep, more, less, head, tail Hotkeys: <ctrl><c>, <ctrl><d> File System: ls, mkdir, cd, pwd, mv, touch, file, find, diff, cmp, du, chmod, find File Editors: gedit, nedit You need a “xterm” emulation – software that emulates an “X” terminal and that connects using the “SSH” Secure Shell protocol. ◦ Windows Use StarNet “X-Win32:” http://www.bu.edu/tech/support/desktop/ distribution/xwindows/xwin32/ ◦ Mac OS X “Terminal” is already installed Why? Darwin, the system on which Apple's Mac OS X is built, is a derivative of 4.4BSD-Lite2 and FreeBSD.
    [Show full text]
  • Introduction Use Runit with Traditional Init (Sysvinit)
    2021/07/26 19:10 (UTC) 1/12 Runit Runit Introduction runit is a UNIX init scheme with service supervision. It is a cross-platform Unix init scheme with service supervision, a replacement for sysvinit, and other init schemes and supervision that are used with the traditional init. runit is compatible with djb's daemontools. In Unix-based computer operating systems, init (short for initialization) is the first process started during booting of the computer system. Init is a daemon process that continues running until the system is shut down. Slackware comes with its own legacy init (/sbin/init) from the sysvinit package, that used to be included in almost all other major Linux distributions. The init daemon (or its replacement) is characterised by Process ID 1 (PID 1). To read on the benefits of runit, see here: http://smarden.org/runit/benefits.html * Unless otherwise stated, all commands in this article are to be run by root. Use runit with traditional init (sysvinit) runit is not provided by Slackware, but a SlackBuild is maintained on https://slackbuilds.org/. It does not have any dependencies. As we do not want yet to replace init with runit, run the slackbuild with CONFIG=no: CONFIG=no ./runit.SlackBuild Then install the resulting package and proceed as follows: mkdir /etc/runit/ /service/ cp -a /usr/doc/runit-*/etc/2 /etc/runit/ /sbin/runsvdir-start & Starting via rc.local For a typical Slackware-stlyle service, you can edit /etc/rc.d/rc.local file if [ -x /sbin/runsvdir-start ]; then /sbin/runsvdir-start & fi and then edit write /etc/rc.d/rc.local_shutdown #!/bin/sh SlackDocs - https://docs.slackware.com/ Last update: 2020/05/06 08:08 (UTC) howtos:slackware_admin:runit https://docs.slackware.com/howtos:slackware_admin:runit RUNIT=x$( /sbin/pidof runsvdir ) if [ "$RUNIT" != x ]; then kill $RUNIT fi Then give rc.local_shutdown executive permission: chmod +x /etc/rc.d/rc.local_shutdown and reboot Starting via inittab (supervised) Remove the entries in /etc/rc.d/rc.local and /etc/rc.d/rc.local_shutdown described above.
    [Show full text]
  • Mac OS X: an Introduction for Support Providers
    Mac OS X: An Introduction for Support Providers Course Information Purpose of Course Mac OS X is the next-generation Macintosh operating system, utilizing a highly robust UNIX core with a brand new simplified user experience. It is the first successful attempt to provide a fully-functional graphical user experience in such an implementation without requiring the user to know or understand UNIX. This course is designed to provide a theoretical foundation for support providers seeking to provide user support for Mac OS X. It assumes the student has performed this role for Mac OS 9, and seeks to ground the student in Mac OS X using Mac OS 9 terms and concepts. Author: Robert Dorsett, manager, AppleCare Product Training & Readiness. Module Length: 2 hours Audience: Phone support, Apple Solutions Experts, Service Providers. Prerequisites: Experience supporting Mac OS 9 Course map: Operating Systems 101 Mac OS 9 and Cooperative Multitasking Mac OS X: Pre-emptive Multitasking and Protected Memory. Mac OS X: Symmetric Multiprocessing Components of Mac OS X The Layered Approach Darwin Core Services Graphics Services Application Environments Aqua Useful Mac OS X Jargon Bundles Frameworks Umbrella Frameworks Mac OS X Installation Initialization Options Installation Options Version 1.0 Copyright © 2001 by Apple Computer, Inc. All Rights Reserved. 1 Startup Keys Mac OS X Setup Assistant Mac OS 9 and Classic Standard Directory Names Quick Answers: Where do my __________ go? More Directory Names A Word on Paths Security UNIX and security Multiple user implementation Root Old Stuff in New Terms INITs in Mac OS X Fonts FKEYs Printing from Mac OS X Disk First Aid and Drive Setup Startup Items Mac OS 9 Control Panels and Functionality mapped to Mac OS X New Stuff to Check Out Review Questions Review Answers Further Reading Change history: 3/19/01: Removed comment about UFS volumes not being selectable by Startup Disk.
    [Show full text]
  • Mandoc: Becoming the Main BSD Manual Toolbox
    mandoc: becoming the main BSD manual toolbox BSDCan 2015, June 13, Ottawa Ingo Schwarze <[email protected]> Cynthia Livingston’sOTTB “Bedifferent” (c) 2013 C. Livingston (with permission) > Ingo Schwarze: mandoc page 2: INTROI BSDCan 2015, June 13, Ottawa Brief history of UNIX documentation • The key point: All documentation in one place and one format. Easy to find, uniform and easy to read and write. Be correct, complete, concise. • 1964: RUNOFF/roffmarkup syntax by Jerome H. Saltzer,MIT. Unobtrusive,diff(1)-friendly,easy to hand-edit, simple tools, high quality output. • 1971: Basic manual structure by Ken Thompson and Dennis Ritchie for the AT&T Version 1 UNIX manuals, Bell Labs. • 1979: man(7) physical markup language for AT&T Version 7 UNIX. • 1989: mdoc(7) semantic markup by Cynthia Livingston for 4.3BSD-Reno. Powerful, self-contained, portable. • 1989: GNU troffbyJames Clarke. • 2001: mdoc(7) rewrite by Werner Lemberg and Ruslan Ermilovfor groff-1.17. • 2008: mandoc(1) started by Kristaps Dzonsons. • 2010: mandoc(1) is the only documentation formatter in the OpenBSD base system. • 2014: mandoc(1) used by default in OpenBSD, FreeBSD, NetBSD, illumos. 16:19:30 What is the mandoc toolbox? → < > Ingo Schwarze: mandoc page 3: INTROIIBSDCan 2015, June 13, Ottawa What is the mandoc toolbox? User perspective:man(1), the manual viewer One comprehensive tool! Normal operation always proceeds in three steps: 1. Find one or more manuals in the file system or using a database by manual name — man(1) — or by search query — apropos(1) =man -k The result of this step can be printed out with man -w.
    [Show full text]