[comp.lang.c] Proposal for a standard C/Operating System Interface Library

rburns%master@Sun.COM (Randy Burns) (09/17/88)

Have you ever wanted to OS perform operations through C more 
easily than through the System command?

Have you ever wished calls to the system 
command were portable accross operating systems? 

Have you ever wished you could more easily transfer your 
knowledge of unix into C programs(i.e. grep'ing or sed'ding a 
string variable and return a pointer to a string)?

Have you ever wished for a familar way to do the 
things you might do in operating batch file or 
shell script on a system which does not support 
a good shell script language (i.e. Apple Macintosh, 
Tandem computers)?

Would you like to see a greater standardization of the 
industry around Unix and C?

Have you ever wished you could get by with learning one
less language rather than struggling with a language like 
the C-shell or bourne shell that you really don't know
very well?

Have you ever wanted OS functions called from C programs to occur 
with a higher level of performance? (I have found this is especially 
important when doing C programs which embed SQL database calls)

Have you been annoyed when you needed to create a shell script
to accompany a small program, needlessly creating an extra file
to confuse the user?

You may wish to consider an idea that just might provide this for us all:
The creation of a standard C library which provides direct calls
to a library containing  functionality found in the most common  
unix utilities (i.e. cp, mv, rm, tr, ls, grep, head, tail,cat,  
sed, awk, date, cal,diff,df,du,mkdir, rmdir, cd, lpr, pwd,
dc, sort, more, find and possibly others). 

The above commands are ones that might be made into library calls
fairly portable accross a *wide* range of existing operating systems. 
Free or public domain versions of most of the utilities either exist 
or will quite soon. I imagine that creating the library would take some
degree of work. The next trick would be to get the libraries commonly 
included with C, C++ compilers and interpreters.

For example the functions might be declared as follows:

int sgrep(string,"pattern","filename");
int filegrep("pattern","filenamein","filenameout");

int sls(string,"filename or patten to be expanded");
int filels("pattern or file name in","filenameout");


Perhaps a C interpreter which provided these functions might become 
quite popular among users of operating systems which are not as rich in 
utilities as unix, or among unix hacks who need to move temporarily 
to another operating system (if it could do simple command line
processing and was available in source form it would not need to be as
powerful as some of the existing interpreters to be quite useful).

The beauty of using C for these functions, is that the general purpose
nature of the language is even further expanded.  I feel the operations
could be made even more powerful using C++. 

A c++ interpreter using a standard operating system interface library 
might even become signifantly more powerful and preferable to using
a shell like sh or csh.

I am considering starting by writing a more detailed article on this. I would 
appreciate feedback from folks on this proposal.  Has anyone else suggested 
this before me? If so who and what have they written? Thanks for your help.

Randy Burns.
 
The above opinions are my own and not those of my employer or consulting
clients.

 

hwe@beta.lanl.gov (Skip Egdorf) (09/18/88)

In article <68769@sun.uucp>, rburns%master@Sun.COM (Randy Burns) writes:
> ... [stuff removed ...]
> 
> Have you ever wished calls to the system 
> command were portable accross operating systems? 
> 
> ... [grep sed find ] etc.
> 
> The above commands are ones that might be made into library calls
> fairly portable accross a *wide* range of existing operating systems. 
> Free or public domain versions of most of the utilities either exist 
> or will quite soon. I imagine that creating the library would take some
> degree of work. The next trick would be to get the libraries commonly 
> included with C, C++ compilers and interpreters.
> 
> ...
>
> A c++ interpreter using a standard operating system interface library 
> might even become signifantly more powerful and preferable to using
> a shell like sh or csh.
> 
> I am considering starting by writing a more detailed article on this. I would 
> appreciate feedback from folks on this proposal.  Has anyone else suggested 
> this before me? If so who and what have they written? Thanks for your help.
> 
> Randy Burns.

Well, not in C. But it HAS been done very successfully 10 years (my God,
has it really been 10 years?) ago.

For a start, look at:

[1] Software Tools; Kernighan and Plauger; Addison-Wesley 1976

[2] A Virtual Operating System; Hall, Scherrer and Sventek;
    CACM V23 N9, Sept 1980

[3] Several early 1980 Unix User's Group / Usenix procedings that include
    the Software Tools User's group papers.

In the late 1970s, several groups took the software tools code, available
from A-W and put it on a wide number of systems from CP-M to MVS, VM, and
CTSS on the Cray (and most in between). This was because the Software
Tools provided most of a Unix V6 environment on anything that had a
FORTRAN compiler. A users group came together at the Toronto Unix User's
group meeting in 1978 (or was it 79? My memory must be going) that
produced a large amount of coordination and several more and more enhanced
tapes. The purpose of this was very similar to what you discuss. We all
worked on systems that were not as friendly as Unix, and the tools were
very portable. There was not really any planning such as you propose.
We all just responded to similar needs.

I recall one Unix User's group meeting some time ago where one of the
sessions was hot and heavy into Unix portability issues. (this was
back when there were still few ports.) Mike O'dell stood up and
politely chastised those discussing this for not learrning from the
experience of the Software Tools folks who had faced and beaten most
of the problems being discussed. I might suggest that you look in the
same place for a start.

					Skip Egdorf
					hwe@lanl.gov