.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"), or it can be a URL (eg, http://www.appx.com).

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> is 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> is the actual file to be opened (ie, /tmp/appx-registration.txt), the pipe to be read (ie, "|ls -l /tmp") or the URL to be read (ie, http://www.appx.com) (Required). If you are opening a file for WRITE or APPEND, Appx will also create the path if necessary.

<open_mode> determines 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> determines 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.

There are 3 special file names: STDIN:, STDOUT: and STDERR:. These allow you to pipe data into an Appx session or pipe data out, or both. For example, you could write a subroutine that opens STDIN: for reading and STDOUT: for writing. You can then pipe data to a command that starts appx and runs this subroutine:

date | appx -a=<your application id> -d=<your database id> -t=SUBR -p="NAME_OF_YOUR_SUBROUTINE"

Your subroutine will then be able to read the output from the 'date' command. If your subroutine opened STDOUT: and wrote data to it, you could pipe the output from appx to another command:

appx -a=<your application id> -d=<your database id> -t=SUBR -p="NAME_OF_YOUR_SUBROUTINE" -s | more

Note the use of -s on the command line. This prevents Appx from outputting special terminal control characters to STDOUT:

Binary File Support - 5.4.4

Starting in Release 5.4.4, you can append 'Binary' to the <open mode> parameter (ie, READ BINARY). In binary mode the <line termination> is automatically set to NONE regardless of whether you pass it or not. When reading a stream opened with the binary parameter you can tell the API how many characters to read, regardless of any embedded LF or CR/LF characters. When writing binary files, you can tell the API how many characters to write, again regardless of any embedded control characters.

Comments:

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

What is the maximum length for the pathname?

-- Erik Gimbergh - 2015-04-15

It will accept a path name up to 32k long.

-- Jean Neron - 2016-03-02

-- PeteBrower - 2011-08-12