DOCSLIB.ORG

D1750R0 a Proposal to Add Process Management to the C++ Standard Library

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
D1750R0 a Proposal to Add Process Management to the C++ Standard Library D1750R0 A Proposal to Add Process Management to the C++ Standard Library Klemens Morgenstern, Jeff Garland, Elias Kosunen, Fatih Bakir June 17, 2019 Contents 1 Revision History 2 2 Introduction 2 3 Motivation and Scope 2 4 Domain Terminology 3 4.1 Processes . 3 4.2 Process Groups . 3 4.3 Pipes . 3 4.4 Environment and Command Line Arguments . 3 5 Survey of facilities in other standard libraries 3 5.1 C/C++ system function . 3 5.2 Java................................................... 3 5.3 Python . 4 5.4 Rust . 4 5.5 Node.js . 4 6 Design Discussion & Examples 5 6.1 Concept ProcessLauncher ...................................... 5 6.2 Concept ProcessInitializer .................................... 5 6.3 Class process .............................................. 6 6.4 Class process_group ......................................... 7 6.5 Class process_io ........................................... 8 6.6 Class environment ........................................... 9 7 Design Decisions 10 7.1 Namespace std versus std::process . 10 7.2 Using a builder method to create . 11 7.3 wait or join .............................................. 11 7.4 Native Operating System Handle Support . 11 7.5 Pipe close and EOF . 11 7.6 Security and User Management Implications . 11 7.7 Extensibility . 12 7.8 Error Handling . 12 7.9 Synchronous Versus Asynchronous and Networking TS . 12 7.10 Integration of iostream and pipes . 12 8 Technical Specification 12 8.1 Header <process> Synopsis . 12 8.2 Class process .............................................. 13 8.3 Class process_error ......................................... 15 8.4 Class process_group ......................................... 15 8.5 Class process_io ........................................... 17 8.6 Class environment ........................................... 17 8.7 Class process_limit_handles .................................... 18 8.8 Namespace this_process ....................................... 19 8.9 Header <pstream> Synopsis . 20 8.10 Classes basic_pipe_read_end, basic_pipe_write_end, basic_pipe . 23 8.11 Class templates basic_pipebuf, basic_opstream, basic_ipstream and basic_pstream . 25 8.12 Classes async_pipe_read_end, async_pipe_write_end, async_pipe . 29 9 Open Questions 33 9.1 Core language impact . 33 10 Acknowledgements 33 11 References 33 1 1 Revision History Initial release. 2 Introduction The creation and management of processes is a widely used and fundamental tool in computing systems. Unfortunately, C++ does not have a portable way to create and manage processes. Most other language standard libraries support facilities to wrap the complexities in support of application programmers. The functionality has been on standard library wishlists going back to 2007. The proposal is based on boost.process which provides cross-platform implementation experience. 3 Motivation and Scope We propose a library to facilitate the following functionality: • create child processes on the current machine • setup streams for communication with child stdout and stderr • communicate with child processes through streams • wait for processes to exit • terminate processes • capture the return result of a child process • manage groups of processes • optionally associate the child-process to the parent-child to children die with their parents, but not vice- versa. The following illustrates an example usage of the proposed library. #include <process> int main() { std::vector<std::string> args { "--version", "--std=c++2a" }; try { std::ipstream pipe_stream; //capture stdout, leave the others as the OS defaults std::process child("gcc", args, std::process_io({}, pipe_stream, {})); std::string line; while (pipe_stream && std::getline(pipe_stream, line) && !line.empty()) { std::cerr << line << std::endl; } child.wait(); } catch (const std::process_error& e) { std::cerr << e.what(); } } Additional user examples can be seen online. 2 4 Domain Terminology 4.1 Processes A process is an instance of a program in execution. A process has at least one thread. A process starts execution in the thread that invokes its main function. A child process is the result of another process creating or spawning the child. 4.2 Process Groups Process groups allow for managing a set of processes at the operating system level. This allows behavior such as process termination to be automatically coordinated by the operating system. For example, child processes in a group can be set to terminate together. 4.3 Pipes A pipe is a unidirectional, serial communication line across processes. A pipe has two ends: a write end and a read end. A pipe is buffered. The size of the buffer is implementation defined. When there’s no data in the buffer, the pipe is called empty. When the buffer is full, the pipe is called full. Reading from an empty pipe is a blocking operation. Writing to a pipe resumes any blocked threads that are waiting to read on that pipe. Writing to a full pipe is a blocking operation. Reading from a pipe resumes any blocked threads that are writing to that pipe. If there are multiple threads reading or writing from the same pipe at the same time the order in which they read the data is unspecified. 4.4 Environment and Command Line Arguments Creation of a child process sometimes involves modifying the environment for the child process. This proposal references a current proposal for referencing a process environment. However, the proposal P1275 would need to be enhanced to support multiple instances of environments for access and modification of child process environment. This proposal currently contains a synopsis of similar functionality. 5 Survey of facilities in other standard libraries 5.1 C/C++ system function C and C++ currently provide a minimal process launching capability via the system function. The C++ function takes a const char* parameter that represents the command string to execute and an integer return code that signifies the execution return status. int result = system("echo \"foo\" > bar.txt"); if (result == 0) { //success } This minimal facility lacks many aspects of process control needed for even basic applications, including access to the standard streams (stdin, stdout, stderr) of the child. In addition it uses the system shell to interpret the command, which is a huge security hazard because of shell injection. 5.2 Java Java provides a ProcessBuilder and stream piping facilities similar to what is proposed here. // ProcessBuilder takes variadic string arguments 3 // or a List<String> var builder = new ProcessBuilder("/bin/cat", "-"); // start()-method will spawn the process // Standard streams are piped automatically Process p = builder.start(); // Write into process stdin new OutputStreamWriter(p.getOutputStream()) .write("foo\n") .close(); // close() needed to flush the buffer // Read from stdout var reader = new BufferedReader( new InputStreamReader(p.getInputStream())); String output = reader.readLine(); assert output == "foo"; System.out.println("Exited with " + p.exitValue()) 5.3 Python from subprocess import run # Command line arguments are all passed in a single list # Standard streams aren’t piped by default result = run([ ’/bin/cat’, ’-’ ], input=’foo\n’, capture_output=True) assert result.stdout == ’foo’ print("Exited with", result.returncode) 5.4 Rust As with other languages Rust provides the ability to pipe the results of the process into the parent. use std::process::{Command, Stdio}; let mut child = Command("/bin/cat") .arg("-") // .args() also available, taking a range // strings passed to .arg() are escaped .stdin(Stdio::piped()) .stdout(Stdio::piped()) .spawn()?; // ?-operator is for error handling child.stdin.as_mut()?.write_all(b"foo\n")?; // .wait_with_output() will, well, wait // child.stdout/stderr exposes standard streams directly let output = child.wait_with_output()?; assert_eq!(b"foo", output.stdout.as_slice()); println!("Exited with {}", output.status.code.unwrap()); 5.5 Node.js const { spawn } = require(’child_process’); 4 // First argument is argv[0], rest of argv passed in a list const p = spawn(’/bin/cat’, [’-’]); p.stdin.write(’foo\n’); // Idiomatic node.js uses callbacks everywhere p.stdout.on(’data’, (data) => { assert.StrictEqual(data, ’foo\n’); }); p.on(’close’, (code) => { console.log(‘Exited with ${code}‘); }); 6 Design Discussion & Examples 6.1 Concept ProcessLauncher The process launcher is a class that impements the actual launch of a process. In most cases there are different versions to do this. On Linux for example, vfork can be required as an alternative for fork on low-memory devices. And while POSIX can change a user by utilizing setuid in a ProcessInitializer, Windows requires the invocation of a different function (CreateProcessAsUserA). As an example for Linux: #include <gnu_cxx_process> __gnu_cxx::vfork_launcher launcher; std::process my_proc("/bin/programm", {}, launcher); or for Windows: __msvc::as_user_launcher{"1234-is-not-a-safe-user-token"}; std::process my_proc("C:\program", {}, launcher); In addition libraries may provide their launchers. The requirement is that there is an actual process with a pid as the result of launching the process. Furthermore, the fact that the launcher has a well-specified launch function allows to launch a process like this: std::process_launcher launcher; auto proc = launcher.launch("/bin/foo", {}); Both versions make sense in their own way: on the one hand using the process constructor fits well in with the STL and it’s RAII classes like thread. On the other hand it actually uses a factory-class, which can be
Load more

Recommended publications
  • Pexpect Documentation Release 4.8
    Pexpect Documentation Release 4.8 Noah Spurrier and contributors Apr 17, 2021 Contents 1 Installation 3 1.1 Requirements...............................................3 2 API Overview 5 2.1 Special EOF and TIMEOUT patterns..................................6 2.2 Find the end of line – CR/LF conventions................................6 2.3 Beware of + and * at the end of patterns.................................7 2.4 Debugging................................................8 2.5 Exceptions................................................8 2.6 Pexpect on Windows...........................................9 3 API documentation 11 3.1 Core pexpect components........................................ 11 3.2 fdpexpect - use pexpect with a file descriptor.............................. 23 3.3 popen_spawn - use pexpect with a piped subprocess.......................... 23 3.4 replwrap - Control read-eval-print-loops................................. 24 3.5 pxssh - control an SSH session...................................... 25 4 Examples 33 5 FAQ 35 6 Common problems 39 6.1 Threads.................................................. 39 6.2 Timing issue with send() and sendline()................................. 39 6.3 Truncated output just before child exits................................. 40 6.4 Controlling SSH on Solaris....................................... 40 6.5 child does not receive full input, emits BEL............................... 40 7 History 41 7.1 Releases................................................. 41 7.2 Moves and forks............................................
    [Show full text]
  • Cygwin User's Guide
    Cygwin User’s Guide Cygwin User’s Guide ii Copyright © Cygwin authors Permission is granted to make and distribute verbatim copies of this documentation provided the copyright notice and this per- mission notice are preserved on all copies. Permission is granted to copy and distribute modified versions of this documentation under the conditions for verbatim copying, provided that the entire resulting derived work is distributed under the terms of a permission notice identical to this one. Permission is granted to copy and distribute translations of this documentation into another language, under the above conditions for modified versions, except that this permission notice may be stated in a translation approved by the Free Software Foundation. Cygwin User’s Guide iii Contents 1 Cygwin Overview 1 1.1 What is it? . .1 1.2 Quick Start Guide for those more experienced with Windows . .1 1.3 Quick Start Guide for those more experienced with UNIX . .1 1.4 Are the Cygwin tools free software? . .2 1.5 A brief history of the Cygwin project . .2 1.6 Highlights of Cygwin Functionality . .3 1.6.1 Introduction . .3 1.6.2 Permissions and Security . .3 1.6.3 File Access . .3 1.6.4 Text Mode vs. Binary Mode . .4 1.6.5 ANSI C Library . .4 1.6.6 Process Creation . .5 1.6.6.1 Problems with process creation . .5 1.6.7 Signals . .6 1.6.8 Sockets . .6 1.6.9 Select . .7 1.7 What’s new and what changed in Cygwin . .7 1.7.1 What’s new and what changed in 3.2 .
    [Show full text]
  • Openextensions POSIX Conformance Document
    z/VM Version 7 Release 1 OpenExtensions POSIX Conformance Document IBM GC24-6298-00 Note: Before you use this information and the product it supports, read the information in “Notices” on page 73. This edition applies to version 7, release 1, modification 0 of IBM z/VM (product number 5741-A09) and to all subsequent releases and modifications until otherwise indicated in new editions. Last updated: 2018-09-12 © Copyright International Business Machines Corporation 1993, 2018. US Government Users Restricted Rights – Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp. Contents List of Tables........................................................................................................ ix About This Document............................................................................................xi Intended Audience......................................................................................................................................xi Conventions Used in This Document.......................................................................................................... xi Where to Find More Information.................................................................................................................xi Links to Other Documents and Websites.............................................................................................. xi How to Send Your Comments to IBM....................................................................xiii Summary of Changes for z/VM
    [Show full text]
  • Cygwin User's Guide
    Cygwin User’s Guide i Cygwin User’s Guide Cygwin User’s Guide ii Copyright © 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012 Red Hat, Inc. Permission is granted to make and distribute verbatim copies of this documentation provided the copyright notice and this per- mission notice are preserved on all copies. Permission is granted to copy and distribute modified versions of this documentation under the conditions for verbatim copying, provided that the entire resulting derived work is distributed under the terms of a permission notice identical to this one. Permission is granted to copy and distribute translations of this documentation into another language, under the above conditions for modified versions, except that this permission notice may be stated in a translation approved by the Free Software Foundation. Cygwin User’s Guide iii Contents 1 Cygwin Overview 1 1.1 What is it? . .1 1.2 Quick Start Guide for those more experienced with Windows . .1 1.3 Quick Start Guide for those more experienced with UNIX . .1 1.4 Are the Cygwin tools free software? . .2 1.5 A brief history of the Cygwin project . .2 1.6 Highlights of Cygwin Functionality . .3 1.6.1 Introduction . .3 1.6.2 Permissions and Security . .3 1.6.3 File Access . .3 1.6.4 Text Mode vs. Binary Mode . .4 1.6.5 ANSI C Library . .5 1.6.6 Process Creation . .5 1.6.6.1 Problems with process creation . .5 1.6.7 Signals . .6 1.6.8 Sockets . .6 1.6.9 Select .
    [Show full text]
  • CS415: Systems Programming
    CS415: Systems Programming Process Related Systems Call (System, Fork, EXEC) Most of the slides in this lecture are either from or adapted from the slides provided by Dr. Ahmad Barghash Creating processes • Method (1) using system • The system function in the standard C library provides an easy way to execute a command from within a program, much as if the command had been typed into a shell. #include <stdlib.h> int main () { int return_value; return_value = system (“ls -l /”); return return_value; } Creating processes • Method (2) using fork and exec • Linux provides one function, fork, that makes a child process that is an exact copy of its parent process • Linux provides another set of functions, the exec family, that causes a particular process to cease being an instance of one program and to instead become an instance of another program • To spawn a new process, you first use fork to make a copy of the current process. Then you use exec to transform one of these processes into an instance of the program you want to spawn int fork(void) • Description: create a child process • Returns: process ID of the new process int fork(void) parent getpid() : 60 fork() getpid() : 60 getppid() : 59 getppid() : 59 fork_pid : 61 parent fork_pid = fork() child fork() getpid() : 61 getppid() : 60 fork_pid : 0 fork() - Example Using fork to duplicate a program’s process #include <stdio.h> #include <sys/types.h> #include <unistd.h> int main () { pid_t child_pid; printf (“the main program process ID is %d\n”, (int) getpid ()); child_pid = fork (); if (child_pid != 0) { printf (“this is the parent process, with id %d\n”, (int) getpid ()); printf (“the child’s process ID is %d\n”, (int) child_pid); } else printf (“this is the child process, with id %d\n”, (int) getpid ()); return 0; } Contd.
    [Show full text]
  • Robustness Testing of the Microsoft Win32 API
    Robustness Testing of the Microsoft Win32 API Charles P. Shelton Philip Koopman Kobey DeVale ECE Department & ICES ECE Department ECE Department Carnegie Mellon University Carnegie Mellon University Carnegie Mellon University Pittsburgh, PA, USA Pittsburgh, PA, USA Pittsburgh, PA, USA [email protected] [email protected] [email protected] Abstract Unfortunately, Windows operating systems have ac- quired a general reputation of being less dependable than Although Microsoft Windows is being deployed in Unix-based operating systems. In particular, the infamous mission-critical applications, little quantitative data has "Blue Screen Of Death" that is displayed as a result of Win- been published about its robustness. We present the results dows system crashes is perceived by many as being far of executing over two million Ballista-generated exception handling tests across 237 functions and system calls more prevalent than the equivalent kernel panics of Unix involving six Windows variants, as well as similar tests operating systems. Additionally, it is a common (although conducted on the Linux operating system. Windows 95, meagerly documented) experience that Windows systems Windows 98, and Windows CE were found to be vulnerable need to be rebooted more often than Unix systems. How- to complete system crashes caused by very simple C ever, there is little if any quantitative data published on the programs for several different functions. No system dependability of Windows, and no objective way to predict crashes were observed on Windows NT, Windows 2000, whether the impending move to Windows 2000 will actu- and Linux. Linux was significantly more graceful at ally improve dependability over either Windows 98 or Win- handling exceptions from system calls in a dows NT.
    [Show full text]
  • Z/OS UNIX Security Fundamentals
    Front cover z/OS UNIX Security Fundamentals The explanation of the z/OS UNIX security model The use of SAF to achieve superior security Professionals’ tips and recommendations to achieve superior security Patrick Kappeler Finn Christensen Jean-Marc Darees Dominique Richard ibm.com/redbooks Redpaper International Technical Support Organization z/OS UNIX Security Fundamentals February 2007 Note: Before using this information and the product it supports, read the information in “Notices” on page vii. First Edition (February 2007) This edition applies to the z/OS UNIX System Services base component in Version 1, Release 7, of z/OS (product number 5694-A01) © Copyright International Business Machines Corporation 2007. All rights reserved. Note to U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp. Contents Notices . vii Trademarks . viii Preface . ix The team that wrote this IBM Redpaper. ix Become a published author . x Comments welcome. xi Chapter 1. Overview of the UNIX operating system model . 1 1.1 What is UNIX?. 2 1.1.1 The POSIX standards . 2 1.2 The UNIX model of operating system . 3 1.2.1 The UNIX kernel . 4 1.2.2 The UNIX processes . 4 1.2.3 Signals . 5 1.2.4 Virtual memory and memory protection . 5 1.2.5 Shell . 5 1.2.6 The UNIX utilities . 6 1.2.7 The UNIX file system . 6 1.2.8 The /etc directory . 7 1.2.9 Daemons. 8 1.3 The UNIX security model . 8 1.3.1 Accessing UNIX . 8 1.3.2 UNIX users and groups.
    [Show full text]
  • A Fork() in the Road Andrew Baumann Jonathan Appavoo Orran Krieger Timothy Roscoe Microsoft Research Boston University Boston University ETH Zurich
    A fork() in the road Andrew Baumann Jonathan Appavoo Orran Krieger Timothy Roscoe Microsoft Research Boston University Boston University ETH Zurich ABSTRACT 50 years later, fork remains the default process creation The received wisdom suggests that Unix’s unusual combi- API on POSIX: Atlidakis et al. [8] found 1304 Ubuntu pack- nation of fork() and exec() for process creation was an ages (7.2% of the total) calling fork, compared to only 41 inspired design. In this paper, we argue that fork was a clever uses of the more modern posix_spawn(). Fork is used by hack for machines and programs of the 1970s that has long almost every Unix shell, major web and database servers (e.g., outlived its usefulness and is now a liability. We catalog the Apache, PostgreSQL, and Oracle), Google Chrome, the Redis ways in which fork is a terrible abstraction for the mod- key-value store, and even Node.js. The received wisdom ap- ern programmer to use, describe how it compromises OS pears to hold that fork is a good design. Every OS textbook implementations, and propose alternatives. we reviewed [4, 7, 9, 35, 75, 78] covered fork in uncritical As the designers and implementers of operating systems, or positive terms, often noting its “simplicity” compared to we should acknowledge that fork’s continued existence as alternatives. Students today are taught that “the fork system a first-class OS primitive holds back systems research, and call is one of Unix’s great ideas” [46] and “there are lots of deprecate it. As educators, we should teach fork as a histor- ways to design APIs for process creation; however, the com- ical artifact, and not the first process creation mechanism bination of fork() and exec() are simple and immensely students encounter.
    [Show full text]
  • Operating System Support for Warehouse-Scale Computing
    Operating system support for warehouse-scale computing Malte Schwarzkopf University of Cambridge Computer Laboratory St John’s College October 2015 This dissertation is submitted for the degree of Doctor of Philosophy Declaration This dissertation is the result of my own work and includes nothing which is the outcome of work done in collaboration except where specifically indicated in the text. This dissertation is not substantially the same as any that I have submitted, or, is being concur- rently submitted for a degree or diploma or other qualification at the University of Cambridge or any other University or similar institution. I further state that no substantial part of my dissertation has already been submitted, or, is being concurrently submitted for any such degree, diploma or other qualification at the University of Cambridge or any other University of similar institution. This dissertation does not exceed the regulation length of 60,000 words, including tables and footnotes. Operating system support for warehouse-scale computing Malte Schwarzkopf Summary Computer technology currently pursues two divergent trends: ever smaller mobile devices bring computing to new everyday contexts, and ever larger-scale data centres remotely back the ap- plications running on these devices. These data centres pose challenges to systems software and the operating system (OS): common OS abstractions are fundamentally scoped to a single machine, while data centre applications treat thousands of machines as a “warehouse-scale computer” (WSC). I argue that making the operating system explicitly aware of their distributed operation can result in significant benefits. This dissertation presents the design of a novel distributed operating system for warehouse-scale computers.
    [Show full text]
  • VSI Openvms System Analysis Tools Manual
    VSI OpenVMS VSI OpenVMS System Analysis Tools Manual Document Number: DO-DSYATM-01A Publication Date: November 2019 Revision Update Information: This is a new manual. Operating System and Version: VSI OpenVMS Integrity Version 8.4-2 VSI OpenVMS Alpha Version 8.4-2L1 VMS Software, Inc., (VSI) Bolton, Massachusetts, USA VSI OpenVMS System Analysis Tools Manual: Copyright © 2019 VMS Software, Inc. (VSI), Bolton, Massachusetts, USA Legal Notice Confidential computer software. Valid license from VSI required for possession, use or copying. Consistent with FAR 12.211 and 12.212, Commercial Computer Software, Computer Software Documentation, and Technical Data for Commercial Items are licensed to the U.S. Government under vendor's standard commercial license. The information contained herein is subject to change without notice. The only warranties for VSI products and services are set forth in the express warranty statements accompanying such products and services. Nothing herein should be construed as constituting an additional warranty. VSI shall not be liable for technical or editorial errors or omissions contained herein. HPE, HPE Integrity, HPE Alpha, and HPE Proliant are trademarks or registered trademarks of Hewlett Packard Enterprise. The VSI OpenVMS documentation set is available on DVD. ii VSI OpenVMS System Analysis Tools Manual Preface .................................................................................................................................... xi 1. About this manual ........................................................................................................
    [Show full text]
  • Linux Processes
    04 0430 CH03 5/22/01 10:13 AM Page 45 3 Processes A RUNNING INSTANCE OF A PROGRAM IS CALLED A PROCESS. If you have two terminal windows showing on your screen, then you are probably running the same terminal program twice—you have two terminal processes. Each terminal window is probably running a shell; each running shell is another process.When you invoke a command from a shell, the corresponding program is executed in a new process; the shell process resumes when that process completes. Advanced programmers often use multiple cooperating processes in a single appli- cation to enable the application to do more than one thing at once, to increase application robustness, and to make use of already-existing programs. Most of the process manipulation functions described in this chapter are similar to those on other UNIX systems. Most are declared in the header file <unistd.h>; check the man page for each function to be sure. 3.1 Looking at Processes Even as you sit down at your computer, there are processes running. Every executing program uses one or more processes. Let’s start by taking a look at the processes already on your computer. 04 0430 CH03 5/22/01 10:13 AM Page 46 46 Chapter 3 Processes 3.1.1 Process IDs Each process in a Linux system is identified by its unique process ID, sometimes referred to as pid. Process IDs are 16-bit numbers that are assigned sequentially by Linux as new processes are created. Every process also has a parent process (except the special init process, described in Section 3.4.3,“Zombie Processes”).Thus, you can think of the processes on a Linux system as arranged in a tree, with the init process at its root.The parent process ID,or ppid, is simply the process ID of the process’s parent.
    [Show full text]
  • Name Synopsis Prerequisites for Compiling Perl On
    Perl version 5.12.4 documentation - perlcygwin NAME README.cygwin - Perl for Cygwin SYNOPSIS This document will help you configure, make, test and install Perlon Cygwin. This document also describes features of Cygwin that willaffect how Perl behaves at runtime. NOTE: There are pre-built Perl packages available for Cygwin and aversion of Perl is provided in the normal Cygwin install. If you donot need to customize the configuration, consider using one of those packages. PREREQUISITES FOR COMPILING PERL ON CYGWIN Cygwin = GNU+Cygnus+Windows (Don't leave UNIX without it) The Cygwin tools are ports of the popular GNU development tools for Win32platforms. They run thanks to the Cygwin library which provides the UNIXsystem calls and environment these programs expect. More informationabout this project can be found at: F<http://www.cygwin.com/> A recent net or commercial release of Cygwin is required. At the time this document was last updated, Cygwin 1.5.24 was current. Cygwin Configuration While building Perl some changes may be necessary to your Cygwin setup sothat Perl builds cleanly. These changes are not required for normalPerl usage. NOTE: The binaries that are built will run on all Win32 versions.They do not depend on your host system (Win9x/WinME, WinNT/Win2K)or your Cygwin configuration (ntea, ntsec, binary/text mounts). The only dependencies come from hard-coded pathnames like /usr/local.However, your host system and Cygwin configuration will affect Perl'sruntime behavior (see TEST). * PATH Set the PATH environment variable so that Configure finds the Cygwinversions of programs. Any Windows directories should be removed ormoved to the end of your PATH.
    [Show full text]