.STREAM OPEN

This subroutine is called to open a file stream.

Usage:

      PASS         <stream_name>              FIELD            SHARE? N
      PASS         <pathname>                 FIELD            SHARE? N
      PASS         <open_mode>                FIELD            SHARE? N
      PASS         <line_termination>         FIELD            SHARE? N
      GOSUB    --- .STREAM OPEN
      *        check for errors
      IF       --- .STREAM OPEN               NE

Description:

This subroutine is called to open a file stream. A file stream can point to an actual file on the filesystem, or it can be output from an O/S command (eg, opening a 'pipe' via a file name of "|dir" or "|ls- l").

The first three parameters are required, and the subroutine will CANCEL if they are are not all received. The <line_termination> parameter is optional.

<stream_name> identifies the symbolic name of the stream used to open the file (Required). This can be any name you desire. All subsequent operations on this stream will be via this name.

<pathname> identifies the actual file to be opened (ie, /tmp/appx-registration.txt) or the pipe to be read (ie, "|ls -l /tmp") (Required). If you are opening a file for WRITE or APPEND, Appx will also create the path if necessary.

<open_mode> identifies how the file will be opened. Valid values are READ, WRITE, and APPEND. You may also just use the first letter of each word (R, W, A).

<line_termination> identifies how each line will be terminated. Valid values are LF, CR/LF or NONE. This parameter is optional, and if not specified will default to CR/LF for Windows based servers and LF for all other servers. These characters will be added to the end of every line when you write it, or removed from every line when you read it.

You can open more than one stream file at at time, so long as the <stream_name> is different. Once opened, a stream file stays open until either it is explicitly closed via .STREAM CLOSE or .STREAM CLOSE ALL or your session ends.

This command is run by the appx engine, not by 'shelling out' to the O/S level, therefore the file will have the permissions of the engine (if you are creating a file) or must be readable by the engine (if you are reading a file). On Linux/Unix systems, if the 'setuid' bit is set, then the permissions will be those of user 'appx'. If you do not have the 'setuid' bit set, then the permissions will be those of whatever user you have the engine configured to impersonate. On Windows the permissions will be those of the current user.

Comments:

Read what other users have said about this page or add your own comments.

-- PeteBrower - 2011-08-12