Welcome to Linux Knowledge Base and Tutorial
"The place where you learn linux"

 Create an AccountHome | Submit News | Your Account  

Tutorial Menu
Linux Tutorial Home
Table of Contents

· Introduction to Operating Systems
· Linux Basics
· Working with the System
· Shells and Utilities
· Editing Files
· Basic Administration
· The Operating System
· The X Windowing System
· The Computer Itself
· Networking
· System Monitoring
· Solving Problems
· Security
· Installing and Upgrading
· Linux and Windows

Man Pages
Linux Topics
Test Your Knowledge

Site Menu
Site Map
Copyright Info
Terms of Use
Privacy Info
Masthead / Impressum
Your Account

Private Messages

News Archive
Submit News
User Articles
Web Links


The Web

Who's Online
There are currently, 73 guest(s) and 0 member(s) that are online.

You are an Anonymous user. You can register for free by clicking here




           #define PERLIO_NOT_STDIO 0    /* For co-existence with stdio only */
           #include <perlio.h>           /* Usually via #include <perl.h> */

           PerlIO *PerlIO_stdin(void);
           PerlIO *PerlIO_stdout(void);
           PerlIO *PerlIO_stderr(void);

           PerlIO *PerlIO_open(const char *path,const char *mode);
           PerlIO *PerlIO_fdopen(int fd, const char *mode);
           PerlIO *PerlIO_reopen(const char *path, const char *mode, PerlIO *old);  /* deprecated */
           int     PerlIO_close(PerlIO *f);

           int     PerlIO_stdoutf(const char *fmt,...)
           int     PerlIO_puts(PerlIO *f,const char *string);
           int     PerlIO_putc(PerlIO *f,int ch);
           int     PerlIO_write(PerlIO *f,const void *buf,size_t numbytes);
           int     PerlIO_printf(PerlIO *f, const char *fmt,...);
           int     PerlIO_vprintf(PerlIO *f, const char *fmt, va_list args);
           int     PerlIO_flush(PerlIO *f);

           int     PerlIO_eof(PerlIO *f);
           int     PerlIO_error(PerlIO *f);
           void    PerlIO_clearerr(PerlIO *f);

           int     PerlIO_getc(PerlIO *d);
           int     PerlIO_ungetc(PerlIO *f,int ch);
           int     PerlIO_read(PerlIO *f, void *buf, size_t numbytes);

           int     PerlIO_fileno(PerlIO *f);

           void    PerlIO_setlinebuf(PerlIO *f);

           Off_t   PerlIO_tell(PerlIO *f);
           int     PerlIO_seek(PerlIO *f, Off_t offset, int whence);
           void    PerlIO_rewind(PerlIO *f);

           int     PerlIO_getpos(PerlIO *f, SV *save);        /* prototype changed */
           int     PerlIO_setpos(PerlIO *f, SV *saved);       /* prototype changed */

           int     PerlIO_fast_gets(PerlIO *f);
           int     PerlIO_has_cntptr(PerlIO *f);
           int     PerlIO_get_cnt(PerlIO *f);
           char   *PerlIO_get_ptr(PerlIO *f);
           void    PerlIO_set_ptrcnt(PerlIO *f, char *ptr, int count);

           int     PerlIO_canset_cnt(PerlIO *f);              /* deprecated */
           void    PerlIO_set_cnt(PerlIO *f, int count);      /* deprecated */

           int     PerlIO_has_base(PerlIO *f);
           char   *PerlIO_get_base(PerlIO *f);
           int     PerlIO_get_bufsiz(PerlIO *f);

       those defined in ANSI C's stdio.h.  The perl headers (in
       particular "perlio.h") will "#define" them to the I/O
       mechanism selected at Configure time.

       The functions are modeled on those in stdio.h, but parame­
       ter order has been "tidied up a little".

       "PerlIO *" takes the place of FILE *. Like FILE * it
       should be treated as opaque (it is probably safe to assume
       it is a pointer to something).

       There are currently three implementations:

       1. USE_STDIO
           All above are #define'd to stdio functions or are
           trivial wrapper functions which call stdio. In this
           case only PerlIO * is a FILE *.  This has been the
           default implementation since the abstraction was
           introduced in perl5.003_02.

       2. USE_SFIO
           A "legacy" implementation in terms of the "sfio"
           library. Used for some specialist applications on Unix
           machines ("sfio" is not widely ported away from Unix).
           Most of above are #define'd to the sfio functions.
           PerlIO * is in this case Sfio_t *.

       3. USE_PERLIO
           Introduced just after perl5.7.0, this is a re-imple­
           mentation of the above abstraction which allows perl
           more control over how IO is done as it decouples IO
           from the way the operating system and C library choose
           to do things. For USE_PERLIO PerlIO * has an extra
           layer of indirection - it is a pointer-to-a-pointer.
           This allows the PerlIO * to remain with a known value
           while swapping the implementation around underneath at
           run time. In this case all the above are true (but
           very simple) functions which call the underlying

           This is the only implementation for which "Per­
           lIO_apply_layers()" does anything "interesting".

           The USE_PERLIO implementation is described in perliol.

       Because "perlio.h" is a thin layer (for efficiency) the
       semantics of these functions are somewhat dependent on the
       underlying implementation.  Where these variations are
       understood they are noted below.

       Unless otherwise noted, functions return 0 on success, or
       a negative value (usually "EOF" which is usually -1) and
           the number of open handles, which may be lower than
           the limit on the number of open files - "errno" may
           not be set when "NULL" is returned if this limit is

           While this currently exists in all three implementa­
           tions perl itself does not use it. As perl does not
           use it, it is not well tested.

           Perl prefers to "dup" the new low-level descriptor to
           the descriptor used by the existing PerlIO. This may
           become the behaviour of this function in the future.

       PerlIO_printf(f,fmt,...), PerlIO_vprintf(f,fmt,a)
           These are fprintf()/vfprintf() equivalents.

           This is printf() equivalent. printf is #defined to
           this function, so it is (currently) legal to use
           "printf(fmt,...)" in perl sources.

       PerlIO_read(f,buf,count), PerlIO_write(f,buf,count)
           These correspond functionally to fread() and fwrite()
           but the arguments and return values are different.
           The PerlIO_read() and PerlIO_write() signatures have
           been modeled on the more sane low level read() and
           write() functions instead: The "file" argument is
           passed first, there is only one "count", and the
           return value can distinguish between error and "EOF".

           Returns a byte count if successful (which may be zero
           or positive), returns negative value and sets "errno"
           on error.  Depending on implementation "errno" may be
           "EINTR" if operation was interrupted by a signal.

           Depending on implementation "errno" may be "EINTR" if
           operation was interrupted by a signal.

       PerlIO_puts(f,s), PerlIO_putc(f,c)
           These correspond to fputs() and fputc().  Note that
           arguments have been revised to have "file" first.

           This corresponds to ungetc().  Note that arguments
           have been revised to have "file" first.  Arranges that
           next read operation will return the byte c.  Despite
           the implied "character" in the name only values in the
           range 0..0xFF are defined. Returns the byte c on suc­
           cess or -1 ("EOF") on error.  The number of bytes that
           can be "pushed back" may vary, only 1 character is

           This corresponds to ferror().  Returns a true/false
           indication of whether there has been an IO error on
           the handle.

           This corresponds to fileno(), note that on some plat­
           forms, the meaning of "fileno" may not match Unix.
           Returns -1 if the handle has no open descriptor asso­
           ciated with it.

           This corresponds to clearerr(), i.e., clears 'error'
           and (usually) 'eof' flags for the "stream". Does not
           return a value.

           This corresponds to fflush().  Sends any buffered
           write data to the underlying file.  If called with
           "NULL" this may flush all open streams (or core dump
           with some USE_STDIO implementattions).  Calling on a
           handle open for read only, or on which last operation
           was a read of some kind may lead to undefined
           behaviour on some USE_STDIO implementations.  The
           USE_PERLIO (layers) implementation tries to behave
           better: it flushes all open streams when passed
           "NULL", and attempts to retain data on read streams
           either in the buffer or by seeking the handle to the
           current logical position.

           This corresponds to fseek().  Sends buffered write
           data to the underlying file, or discards any buffered
           read data, then positions the file desciptor as speci­
           fied by offset and whence (sic).  This is the correct
           thing to do when switching between read and write on
           the same handle (see issues with PerlIO_flush()
           above).  Offset is of type "Off_t" which is a perl
           Configure value which may not be same as stdio's

           This corresponds to ftell().  Returns the current file
           position, or (Off_t) -1 on error.  May just return
           value system "knows" without making a system call or
           checking the underlying file descriptor (so use on
           shared file descriptors is not safe without a Per­
           lIO_seek()). Return value is of type "Off_t" which is
           a perl Configure value which may not be same as
           stdio's "off_t".

               PerlIO_seek(f,(Off_t)0L, SEEK_SET);

           This corresponds to tmpfile(), i.e., returns an anony­
           mous PerlIO or NULL on error.  The system will attempt
           to automatically delete the file when closed.  On Unix
           the file is usually "unlink"-ed just after it is cre­
           ated so it does not matter how it gets closed. On
           other systems the file may only be deleted if closed
           via PerlIO_close() and/or the program exits via
           "exit".  Depending on the implementation there may be
           "race conditions" which allow other processes access
           to the file, though in general it will be safer in
           this regard than ad. hoc. schemes.

           This corresponds to setlinebuf().  Does not return a
           value. What constitutes a "line" is implementation
           dependent but usually means that writing "\n" flushes
           the buffer.  What happens with things like
           "this\nthat" is uncertain.  (Perl core uses it only
           when "dumping"; it has nothing to do with $|

       Co-existence with stdio

       There is outline support for co-existence of PerlIO with
       stdio.  Obviously if PerlIO is implemented in terms of
       stdio there is no problem. However in other cases then
       mechanisms must exist to create a FILE * which can be
       passed to library code which is going to use stdio calls.

       The first step is to add this line:

          #define PERLIO_NOT_STDIO 0

       before including any perl header files. (This will proba­
       bly become the default at some point).  That prevents
       "perlio.h" from attempting to #define stdio functions onto
       PerlIO functions.

       XS code is probably better using "typemap" if it expects
       FILE * arguments.  The standard typemap will be adjusted
       to comprehend any changes in this area.

           Used to get a PerlIO * from a FILE *.

           The mode argument should be a string as would be
           passed to fopen/PerlIO_open.  If it is NULL then - for
           legacy support - the code will (depending upon the
           passing to code expecting to be compiled and linked
           with ANSI C stdio.h.  The mode argument should be a
           string as would be passed to fopen/PerlIO_open.  If it
           is NULL then - for legacy support - the FILE * is
           opened in same mode as the PerlIO *.

           The fact that such a FILE * has been 'exported' is
           recorded, (normally by pushing a new :stdio "layer"
           onto the PerlIO *), which may affect future PerlIO
           operations on the original PerlIO *.  You should not
           call "fclose()" on the file unless you call "Per­
           lIO_releaseFILE()" to disassociate it from the PerlIO
           *.  (Do not use PerlIO_importFILE() for doing the dis­

           Calling this function repeatedly will create a FILE *
           on each call (and will push an :stdio layer each time
           as well).

           Calling PerlIO_releaseFILE informs PerlIO that all use
           of FILE * is complete. It is removed from the list of
           'exported' FILE *s, and the associated PerlIO * should
           revert to its original behaviour.

           Use this to disassociate a file from a PerlIO * that
           was associated using PerlIO_exportFILE().

           Returns a native FILE * used by a stdio layer. If
           there is none, it will create one with PerlIO_export­
           FILE. In either case the FILE * should be considered
           as belonging to PerlIO subsystem and should only be
           closed by calling "PerlIO_close()".

       "Fast gets" Functions

       In addition to standard-like API defined so far above
       there is an "implementation" interface which allows perl
       to get at internals of PerlIO.  The following calls corre­
       spond to the various FILE_xxx macros determined by Config­
       ure - or their equivalent in other implementations. This
       section is really of interest to only those concerned with
       detailed perl-core behaviour, implementing a PerlIO map­
       ping or writing code which can make use of the "read
       ahead" that has been done by the IO system in the same way
       perl does. Note that any code that uses these interfaces
       must be prepared to do things the traditional way if a
       handle does not support them.

           Returns true if implementation has all the interfaces
           negative return means no more bytes available.

           Return pointer to next readable byte in buffer,
           accessing via the pointer (dereferencing) is only safe
           if PerlIO_get_cnt() has returned a positive value.
           Only positive offsets up to value returned by Per­
           lIO_get_cnt() are allowed.

           Set pointer into buffer, and a count of bytes still in
           the buffer. Should be used only to set pointer to
           within range implied by previous calls to "Per­
           lIO_get_ptr" and "PerlIO_get_cnt". The two values must
           be consistent with each other (implementation may only
           use one or the other or may require both).

           Implementation can adjust its idea of number of bytes
           in the buffer.  Do not use this - use Per­

           Obscure - set count of bytes in the buffer. Depre­
           cated.  Only usable if PerlIO_canset_cnt() returns
           true.  Currently used in only doio.c to force count
           less than -1 to -1.  Perhaps should be Per­
           lIO_set_empty or similar.  This call may actually do
           nothing if "count" is deduced from pointer and a
           "limit".  Do not use this - use PerlIO_set_ptrcnt().

           Returns true if implementation has a buffer, and can
           return pointer to whole buffer and its size. Used by
           perl for -T / -B tests.  Other uses would be very

           Return start of buffer. Access only positive offsets
           in the buffer up to the value returned by Per­

           Return the total number of bytes in the buffer, this
           is neither the number that can be read, nor the amount
           of memory allocated to the buffer. Rather it is what
           the operating system and/or implementation happened to
           "read()" (or whatever) last time IO was requested.

       Other Functions

           imode is "O_BINARY" or "O_TEXT".

           layers is a string of layers to apply, only ":crlf"
           makes sense in the non USE_PERLIO case. (As of perl5.8
           ":raw" is deprecated in favour of passing NULL.)

           Portable cases are:


           On Unix these calls probably have no effect whatso­
           ever.  Elsewhere they alter "\n" to CR,LF translation
           and possibly cause a special text "end of file" indi­
           cator to be written or honoured on read. The effect of
           making the call after doing any IO to the handle
           depends on the implementation. (It may be ignored,
           affect any data which is already buffered as well, or
           only apply to subsequent data.)

           PerlIO_debug is a printf()-like function which can be
           used for debugging.  No return value. Its main use is
           inside PerlIO where using real printf, warn() etc.
           would recursively call PerlIO and be a problem.

           PerlIO_debug writes to the file named by $ENV{'PER­
           LIO_DEBUG'} typical use might be

             Bourne shells (sh, ksh, bash, zsh, ash, ...):
              PERLIO_DEBUG=/dev/tty ./perl somescript some args

              setenv PERLIO_DEBUG /dev/tty
              ./perl somescript some args

             If you have the "env" utility:
              env PERLIO_DEBUG=/dev/tty ./perl somescript some args

              set PERLIO_DEBUG=CON
              perl somescript some args

           If $ENV{'PERLIO_DEBUG'} is not set PerlIO_debug() is a

perl v5.8.1                 2003-09-02                PERLAPIO(1)

An undefined database error occurred. SELECT distinct pages.pagepath,pages.pageid FROM pages, page2command WHERE pages.pageid = page2command.pageid AND commandid =

Show your Support for the Linux Tutorial

Purchase one of the products from our new online shop. For each product you purchase, the Linux Tutorial gets a portion of the proceeds to help keep us going.



Security Code
Security Code
Type Security Code

Don't have an account yet? You can create one. As a registered user you have some advantages like theme manager, comments configuration and post comments with your name.

Help if you can!

Amazon Wish List

Did You Know?
You can help in many different ways.


Tell a Friend About Us

Bookmark and Share

Web site powered by PHP-Nuke

Is this information useful? At the very least you can help by spreading the word to your favorite newsgroups, mailing lists and forums.
All logos and trademarks in this site are property of their respective owner. The comments are property of their posters. Articles are the property of their respective owners. Unless otherwise stated in the body of the article, article content (C) 1994-2013 by James Mohr. All rights reserved. The stylized page/paper, as well as the terms "The Linux Tutorial", "The Linux Server Tutorial", "The Linux Knowledge Base and Tutorial" and "The place where you learn Linux" are service marks of James Mohr. All rights reserved.
The Linux Knowledge Base and Tutorial may contain links to sites on the Internet, which are owned and operated by third parties. The Linux Tutorial is not responsible for the content of any such third-party site. By viewing/utilizing this web site, you have agreed to our disclaimer, terms of use and privacy policy. Use of automated download software ("harvesters") such as wget, httrack, etc. causes the site to quickly exceed its bandwidth limitation and are therefore expressly prohibited. For more details on this, take a look here

PHP-Nuke Copyright © 2004 by Francisco Burzi. This is free software, and you may redistribute it under the GPL. PHP-Nuke comes with absolutely no warranty, for details, see the license.
Page Generation: 0.09 Seconds