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:
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 >barThe > 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:
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 <barHere, 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 | bazThis 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.
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.
26 January 2018
Up: WFDB Applications Guide
Please e-mail your comments and suggestions to firstname.lastname@example.org, or post them to:PhysioNet
Updated 26 January 2018