yost@esquire.UUCP (David A. Yost) (02/28/90)
There world is divided into two kinds of programs:
1. Simple data manipulation batch programs (e.g. grep)
2. All other programs.
Unfortunately, Icon doesn't reach much beyond Class 1.
It would be great to be able to use Icon for all programs.
There are many reasons write programs on unix in Icon instead
of the shell or C, and I'm sure we all know what those are.
Unfortunately, those reasons don't stand a chance against
the reason why you can't use Icon:
The vast majority of unix system calls are not supported.
As a result, Icon has these deficiencies, among others:
Lack of sophistication in the running of subprocesses:
Keyboard interrupt while a system() command is ignored
No way to run a unix command and capture its output in a variable
You can't run a program in the background and get its process (group)
id for a later kill
No fork, exec, wait, etc.
No trapping of signals, and therefore no cleanup on forced exit,
no timeouts
Has anyone implemented more of the unix system calls?
Would you please tell us about it?
Icon is so nice. It's a shame it can't be used for more things.
--dave yost
yost@dpw.com or uunet!esquire!yost
Please ignore the From or Reply-To fields above, if different.
P.S.
Here is a routine that adds a little to Icon's capability to replace
shell scripts:
# Run a command with the contents of an Icon string variable as input
# Note: If the string is not newline-terminated, it will appear to the
# command as if it were. There are workarounds for this
procedure
tosystem (inputstring, command)
return system ("<<'**END**' " || command || "\n" ||
inputstring || if inputstring[-1] ~== "\n" then "\n" else "" ||
"**END**\n")
end