I've been trying to learn how one would use pascal programs to be used in shell scripts.
The original pascal used the program header to specify such input, output interfaces. ie;
Program foo(input, output, file1, file2) ;
The input and output are the standard in, out but are text file types. TurboPascal on DOS mostly forgot about this.
Building shell commands with pascal seems promising.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Look at ParamCount and ParamStr in the docs; a quick google search found it here:
http://rush3d.com/reference/gpc-20040516/ParamCount.html
There is also a page on this (again, a quick Google search):
http://rush3d.com/reference/gpc-20040516/Accessing-Command-Line- Arguments.html
On May 6, 2005, at 9:40 AM, Rick Engebretson wrote:
I've been trying to learn how one would use pascal programs to be used in shell scripts.
The original pascal used the program header to specify such input, output interfaces. ie;
Program foo(input, output, file1, file2) ;
The input and output are the standard in, out but are text file types. TurboPascal on DOS mostly forgot about this.
Building shell commands with pascal seems promising.
- ----------------------------------------------------------- Frank D. Engel, Jr. fde101@fjrhome.net
$ ln -s /usr/share/kjvbible /usr/manual $ true | cat /usr/manual | grep "John 3:16" John 3:16 For God so loved the world, that he gave his only begotten Son, that whosoever believeth in him should not perish, but have everlasting life. $
___________________________________________________________ $0 Web Hosting with up to 200MB web space, 1000 MB Transfer 10 Personalized POP and Web E-mail Accounts, and much more. Signup at www.doteasy.com
Rick Engebretson wrote:
I've been trying to learn how one would use pascal programs to be used in shell scripts.
The original pascal used the program header to specify such input, output interfaces. ie;
Program foo(input, output, file1, file2) ;The input and output are the standard in, out but are text file types. TurboPascal on DOS mostly forgot about this.
Not really. BP supports `Input' and `Output', though it doesn't require declaring them in the program header. GPC does the same, except in ISO Pascal modes.
Also, BP's CRT unit redirects `Input' and `Output' automatically. Again, GPC's CRT unit does the same. For programs used in shell scripts, that's often irrelevant as batch mode programs don't use CRT anyway. (And if the scripts are meant to call interactive programs, the redirection is fine again.) In case you need a program that uses CRT sometimes, but not always (e.g., depending on command-line arguments), you can re-open `Input' and `Output' to '' (empty name, BP compatible) or '-' (as in many Unix programs) again.
For the arguments, Frank D. Engel, Jr. already mentioned `ParamCount' and `ParamStr' (also BP compatible).
Automatically assigning addtional files mentioned in the header to the names given in arguments has been discussed, but I'm not really convinced of its usefulness. Many programs need to accept options apart from file names. So this 1:1 mapping would work only for simple cases.
Frank
Frank Heckenbach wrote:
Rick Engebretson wrote:
I've been trying to learn how one would use pascal programs to be used in shell scripts.
The original pascal used the program header to specify such input, output interfaces. ie;
Program foo(input, output, file1, file2) ;
The input and output are the standard in, out but are text file types. TurboPascal on DOS mostly forgot about this.
Not really. BP supports `Input' and `Output', though it doesn't require declaring them in the program header. GPC does the same, except in ISO Pascal modes.
Also, BP's CRT unit redirects `Input' and `Output' automatically. Again, GPC's CRT unit does the same. For programs used in shell scripts, that's often irrelevant as batch mode programs don't use CRT anyway. (And if the scripts are meant to call interactive programs, the redirection is fine again.) In case you need a program that uses CRT sometimes, but not always (e.g., depending on command-line arguments), you can re-open `Input' and `Output' to '' (empty name, BP compatible) or '-' (as in many Unix programs) again.
For the arguments, Frank D. Engel, Jr. already mentioned `ParamCount' and `ParamStr' (also BP compatible).
Automatically assigning addtional files mentioned in the header to the names given in arguments has been discussed, but I'm not really convinced of its usefulness. Many programs need to accept options apart from file names. So this 1:1 mapping would work only for simple cases.
Frank
I appreciate your response. I'm familiar with the paramstr and paramcount and some of the rest.
An old book, "TurboPascal Programmers' Library (1987)" discusses the topic as "filters". Some compiler flags are set for this use (get and put buffers are created). Old Unix and newer Linux books cover the topic a little, too. With C.
Shell facilities like timers, pipes, forks, job control, buffers, process management, event signals are available. For example, a pascal framebuffer draw routine uses numeric input and outputs to /dev/fb0. None of this is text input or output. Perhaps it would be best, however, to convert to pure text.
I don't know. That's why I was looking for some references.
Rick Engebretson wrote:
An old book, "TurboPascal Programmers' Library (1987)" discusses the topic as "filters". Some compiler flags are set for this use (get and put buffers are created). Old Unix and newer Linux books cover the topic a little, too. With C.
I remember BP had a special call to set larger (than default) text file buffers, which was rather clumsy to use. Anyway, writing filters is, of course, also possible with default buffer sizes (which are larger in GPC than in BP). Any plain program that reads from `Input' (only) and writes to `Output', and does not use CRT, will work as a filter, both with BP and GPC, both under Dos and Unix, for all I know.
For non-text filters, it's possible (in BP and GPC) to assign typed or untyped files to '' (GPC also allows '-'), and access them instead of `Input' and `Output'. (Though mixing both `Input'/`Output' and your own file variables) can lead to unpredicatable results, as both do their own buffering.
Shell facilities like timers, pipes, forks, job control, buffers, process management, event signals are available.
Sure. For the shell calling the Pascal program they work as usual (unless the Pascal program itself captures some of them, which CRT does and probably some other libraries, but again those that wouldn't usually be used in batch programs). For Pascal programs, these facilities are also available, of course -- some have already interfaces in gpc.pas (timers, signals, etc.), others might require more interfaces (I've added them on an as-needed basis so far).
For example, a pascal framebuffer draw routine uses numeric input and outputs to /dev/fb0. None of this is text input or output. Perhaps it would be best, however, to convert to pure text.
I'm not sure what you mean here. /dev/fb0 is the interface to the graphics framebuffer. Writing text (i.e., ASCII values) to it os rather pointless. You'd have to use your own fonts os whatever in order to display characters. Or write to /dev/tty<n> (which is usually assigned to `Output') which is the text interface of the framebuffer.
Though mixing text and graphics might lead to strange results as the text framebuffer can overwrite your graphics, unless you restrict it via stty settings. So for a really mixed text/graphics output, I guess you'll have to use your own font routines, just as other graphics libraries do.
Frank
Frank Heckenbach wrote:
... snip ...
Automatically assigning addtional files mentioned in the header to the names given in arguments has been discussed, but I'm not really convinced of its usefulness. Many programs need to accept options apart from file names. So this 1:1 mapping would work only for simple cases.
PascalP did that, but limited it to names mentioned within parentheses. I.E:
PROGRAM foo(alpha, beta, gamma, input, output) .... BEGIN .... END.
could be run with a command line explicitly using parentheses:
foo (file1, , file3)
and would access alpha, beta, gamma (assuming declared to be files) as the local files named file1, beta, file3. This only changed the default local ids attached to those files, and could still be over-ridden.
For detailed command line work the whole command line was available to the program as the one line text file named "cmd". So something like:
VAR cmd : text; BEGIN reset(cmd); (* The default id for a file is the Pascal name *) read(cmd, somewhere); ...
would gather the command line for programmatic parsing and usage. Redirection with < and > is stripped from the command line.
CBFalconer wrote:
PascalP did that, but limited it to names mentioned within parentheses. I.E:
PROGRAM foo(alpha, beta, gamma, input, output) .... BEGIN .... END.
could be run with a command line explicitly using parentheses:
foo (file1, , file3)
and would access alpha, beta, gamma (assuming declared to be files) as the local files named file1, beta, file3. This only changed the default local ids attached to those files, and could still be over-ridden.
For detailed command line work the whole command line was available to the program as the one line text file named "cmd". So something like:
VAR cmd : text; BEGIN reset(cmd); (* The default id for a file is the Pascal name *) read(cmd, somewhere); ...
would gather the command line for programmatic parsing and usage. Redirection with < and > is stripped from the command line.
Thank you. Good starting point.
There are many shells out there now. I like and understand TCL. Perl and Python are popular, but I'm too old to learn them. Kurt Wall, in "Linux Programming by Example," describes pipes down to the kernel level.
So I'm picking up references, bit by bit.
Thanks again, Rick.
Rick Engebretson wrote:
CBFalconer wrote:
PascalP did that, but limited it to names mentioned within parentheses. I.E:
PROGRAM foo(alpha, beta, gamma, input, output) .... BEGIN .... END.
could be run with a command line explicitly using parentheses:
foo (file1, , file3)
and would access alpha, beta, gamma (assuming declared to be files) as the local files named file1, beta, file3. This only changed the default local ids attached to those files, and could still be over-ridden.
For detailed command line work the whole command line was available to the program as the one line text file named "cmd". So something like:
VAR cmd : text; BEGIN reset(cmd); (* The default id for a file is the Pascal name *) read(cmd, somewhere); ...
would gather the command line for programmatic parsing and usage. Redirection with < and > is stripped from the command line.
Thank you. Good starting point.
There are many shells out there now. I like and understand TCL. Perl and Python are popular, but I'm too old to learn them. Kurt Wall, in "Linux Programming by Example," describes pipes down to the kernel level.
So I'm picking up references, bit by bit.
Most of the details are available on my site, in:
http://cbfalconer.home.att.net/download/ppmanual.zip
and you can also find a MSDOS port of the compiler proper, but not the code generators. The binaries for all for CP/M are available in the download/cpm directory.
CBFalconer wrote:
Rick Engebretson wrote:
CBFalconer wrote:
PascalP did that, but limited it to names mentioned within parentheses. I.E:
PROGRAM foo(alpha, beta, gamma, input, output) .... BEGIN .... END.
could be run with a command line explicitly using parentheses:
foo (file1, , file3)
and would access alpha, beta, gamma (assuming declared to be files) as the local files named file1, beta, file3. This only changed the default local ids attached to those files, and could still be over-ridden.
For detailed command line work the whole command line was available to the program as the one line text file named "cmd". So something like:
VAR cmd : text; BEGIN reset(cmd); (* The default id for a file is the Pascal name *) read(cmd, somewhere); ...
would gather the command line for programmatic parsing and usage. Redirection with < and > is stripped from the command line.
Thank you. Good starting point.
There are many shells out there now. I like and understand TCL. Perl and Python are popular, but I'm too old to learn them. Kurt Wall, in "Linux Programming by Example," describes pipes down to the kernel level.
So I'm picking up references, bit by bit.
Most of the details are available on my site, in:
http://cbfalconer.home.att.net/download/ppmanual.zip
and you can also find a MSDOS port of the compiler proper, but not the code generators. The binaries for all for CP/M are available in the download/cpm directory.
Quite remarkable. You covered most of this thirty years ago. Thanks for the link.
The I/O methods CBFalconer describes should work in a TCL shell.
Compared to the Bash shell, the TCL shell has an expanded set of I/O redirection operations. (see exec command). TCL uses the term "channels" for any I/O file type..
Thanks for the feedback. . . Rick.
I was able to hack and compile the FPC tcl unit and demo using the fpc compiler. I used a separate install of tcl8.0.p2. I'll try tcl8.0.5 and others over time.
This is what the FPC unit does; TCL is a C library of functions that are used to compile TCL shell commands. New TCL shell commands can be created that suit specific purposes. An example might be a new device driver. This FPC unit allows you to program the new TCL shell command in Pascal instead of C. Basically, anything Pascal can do can be "managed" in a powerful shell environment.
I'll do my best to clean up the hacks. Most were related to FPC linking and Windows portability. I just cut out the Windows stuff anyway. The GPC version might link better.
This is probably a better way to I/O to Pascal than discussed earlier. Anyway, it seems to work.
The fpc TCL unit and demo work better on tcl8.0.5.
The main trick to interfacing tcl script channels (and other tcl types) is procedural-types. (Both fpc and gpc support them.) The types declared in the tcl unit need to conform to the tcl C library structures. So it seems once object pascal is used to build the actual tcl command, a large improvement in the tcl language results.
Sort of like a Pascal TclX.
The original FPC-TCL unit can be broken into several separate units.
An appropriate breakdown might be;
tcl_commands unit (to build and register a tcl command), tcl_channels unit (including file and socket channel types), tcl_events (...), tcl_hashtables, tcl_interpreters, tcl_namespaces, tcl_objects, tcl_strings, tcl_variables.
Thus, getting started with only the tcl_command unit is simpler.
I have not yet figured out why the FPC-TCL unit author did not use the ParamStr, and ParamCount functions. argc and argv are the glue between TCL commands. I don't understand the approach taken in the FPC unit.
Rick Engebretson wrote:
The original FPC-TCL unit can be broken into several separate units.
An appropriate breakdown might be;
tcl_commands unit (to build and register a tcl command), tcl_channels unit (including file and socket channel types), tcl_events (...), tcl_hashtables, tcl_interpreters, tcl_namespaces, tcl_objects, tcl_strings, tcl_variables.
Thus, getting started with only the tcl_command unit is simpler.
I have not yet figured out why the FPC-TCL unit author did not use the ParamStr, and ParamCount functions. argc and argv are the glue between TCL commands. I don't understand the approach taken in the FPC unit.
A TCL shell binding works, but differently than described above.
First, as the FPC:TCL demo does, creating a fully functional TCL interpreter shell from pascal is easy. Most of the above listed pascal interfaces don't add much functionality for the complexity added.
Second, the pascal functions ParamStr and ParamCount seem to work. So I don't know why the FPC:TCL unit doesn't use them.
Third, the functionality I'm seeking ( instrumentation multiplexer ), seems to be better provided in the Zshell, not the TCLshell. The TCLshell binding might not add much anyway.
Lastly, the Linux (Unix) "socketpair" function is obscure.
Endless learning process underway. Lots of terrific work to be re-discovered.
-
CBFalconer -
Frank D. Engel, Jr. -
Frank Heckenbach -
Rick Engebretson