Next: A2M(1) Up: WFDB Applications Guide Previous: Introduction

Frequently Asked Questions

(and Frequently Exclaimed Exclamations)

I double-clicked on the program icon, and nothing happens!
I typed the program name in the 'Run...' dialog, and nothing happens!

Don't do this!

With few exceptions, PhysioToolkit applications run in text mode (i.e., they do not include a graphical user interface). These programs are intended to be run within a terminal emulator using a command-line interface. In most cases, if you attempt to run them by clicking on their icons or names, or by entering the program name in the MS-Windows Run... dialog box, these programs will open a DOS box, print a usage summary, and exit, usually much too fast for you to read anything.

By far the best way to use these programs under MS-Windows is to install a Unix-compatible terminal emulator and shell in which to run them. The best of these is also free; if you have not already done so, download and install the Cygwin software package. This package includes bash (the GNU Bourne Again Shell), and a terminal emulator in which to run it. After a standard installation of Cygwin, you can launch a terminal emulator and bash by clicking on the Cygwin icon that will have been installed on your desktop.

If you do not wish to use Cygwin, it is possible to run text-mode applications under MS-Windows within a DOS box, but there are many limitations of command.com that may prove frustrating. In particular, command.com supports a relatively small space for environment variables that is not secure against buffer overruns, and has idiosyncratic filename globbing behavior.

What does the message "init: can't open header for ..." mean?

This message can be produced by any application linked to the WFDB library, including rdsamp(1) and rdann(1). In order to read data files, these applications need to find a header (.hea) file for the input record you specify. The message indicates that the header file was not found in any of the expected places, or that it was unreadable. There are three common reasons why this can happen:

The record name supplied to the application is not correct. Record names are not file names (if this doesn't sound familiar yet, go back and read the introduction again). If you wish to read, for example, a signal file named slp60.dat using rdsamp, you must specify the name of the record to which this file belongs (slp60) after the -r option, and not the name of the file itself. Whatever follows "init: can't open header for ..." is what the application thinks is the name of the record you wish to read. Also, be aware that case matters in record names, even under operating systems that ignore case in file names. Thus "SLP60" is not a valid record name; "slp60" is.
The header file is missing. If you download signal (.dat) or annotation (.atr, .qrs, etc.) files, be sure to download the corresponding .hea files from the same locations.
The list of locations to be searched does not include the location of the header file. WFDB applications find their input files by searching a list of locations specified by the WFDB path (the environment variable WFDB, or a default list of locations if WFDB has not been set). The WFDB path normally includes the current directory, but this may not be true if the WFDB path has been modified; the current directory must appear explicitly (either as a "." or as an empty component in the path) in order to be included in the list of locations to be searched. For further information, see "The Database Path and Other Environment Variables" in the WFDB Programmer's Guide.

How can I save the output of ... in a file?
How can one program read another's output?

If you are running programs from a command prompt (by typing commands into a terminal emulator window or an MS-DOS box), these things can be done easily.

If you have ever used GNU/Linux, Unix, or MS-DOS, you may have captured the output of a program by redirecting it to a file, like this:

    foo >bar

The > operator redirects foo's standard output (which would normally appear on-screen) into a file named bar. If bar exists already, its contents are replaced. If you wish to append foo's output to whatever is already contained in bar, use a command such as this instead:

    foo >>bar

There is an analogous operator that arranges for a program's standard input (which would normally be read from whatever you type on the keyboard) to be read from a file instead:

    baz <bar

Here, the < operator arranges for baz to read its input from a file named bar. If bar was created by foo, then this command allows baz to read foo's output.

You can combine input and output redirection in a single command using the pipe (|) operator:

    foo | baz

This command runs foo and sends its standard output directly to baz, without requiring an intermediate file. True multitasking operating systems such as Unix and GNU/Linux allow both programs to run (apparently) simultaneously; under MS-DOS or MS-Windows, the first program runs to completion before the second one begins execution.

You can use these techniques whenever you run programs from a command prompt, whether those programs are among those available here or obtained from some other source. You can use the same techniques with programs you write yourself; the only requirement is that your programs must read from the standard input and write to the standard output (i.e., they must not attempt to bypass the standard input/output mechanism by reading directly from the keyboard or writing directly to the screen).

These operators (>, >>, <, and |) are supported by all shells (command interpreters) under Unix, GNU/Linux, and MS-DOS (including those that run within MS-DOS boxes or other types of terminal emulators under MS-Windows). For further information, please refer to the documentation for your shell or command interpreter.

Where else can I find answers to my questions about this software?

If you haven't read the introduction to this guide yet, do so now. It answers many frequently asked questions by describing the common behavior of many of the WFDB applications. It also describes the typographic and organizational conventions used in the remainder of this guide.

Many more questions are asked and answered in the PhysioNet FAQ.

8 March 2019

Up: WFDB Applications Guide

Please e-mail your comments and suggestions to webmaster@physionet.org, or post them to:

PhysioNet
MIT Room E25-505A
77 Massachusetts Avenue
Cambridge, MA 02139 USA

Updated 8 March 2019