Responding to a request from Monika.
steve@watchfield.com ("Stephen F. K. Leach") writes:
> This must be one of the commonest requests - and it is something of
> a mystery to me why Poplog does not provide some nice "poppish"
> interfaces.
It turned out from email Monika sent me that sysobey did *exactly*
what she wanted.
> We have sysobey, piputils, and run_unix_program - but
> they are either simple-but-inflexible or complex-but-useless.
Steve, you are exaggerating!
run_unix_program is complex, and incomplete (see below), but it is not
useless. (You may have experienced an earlier version, which had a
couple of bugs, fixed several years ago.)
My own experience has been that some of these utilities provide
fairly general mechanisms that most people will not use directly
and which can be packaged into all sorts of simple, and inflexible,
but VERY useful utilities.
E.g. Every day I make frequent use of VED commands, which run
unix utilities, all implemented in terms of other more general, but
less easy to use utilities.
ENTER grep
(We have a local version)
ENTER grepmail
(a local extension for searching mail files)
ENTER rsh <machine> <command>
run command on machine and read output into Ved buffer.
ENTER bg <command>
run command in background (e.g. launch netscape on URL
in current Ved bugger).
ENTER csh <command>
ENTER sh <command>
For users here who use different shells I produced
ENTER unix <command>
It finds out what your $SHELL variable holds and uses that. It's
in
ftp://ftp.cs.bham.ac.uk/pub/dist/poplog/auto/ved_unix.p
Likewise there are regularly used utilities for running latex, xdvi,
dvips and for sending, reading and responding to email or news, etc.
(I'll use ved_postnews to post this, having used ved_followup to
prepare the reply template).
If what you are assuming is that instead of all these specialised
(inflexible) commands users should use some single general command to
spawn unix processes I would disagree.
On the other hand, I do agree that for those who want to do something
not already catered for it can sometimes be very difficult. E.g.
Give a command which opens an xterm window running pop11
or some other interactive program.
Give a command which opens an xterm window running pop11
on a remote machine
> Here are some ideas for making idiomatic UNIX programming more
> straightforward. The first part of the message is about enhancing
> or replacing -sysobey- with a new procedure called -system-. The
> second part discusses making environment variables simpler.
It is very important to distinguish unix experts from other users.
Increasingly the people who use unix are not developers but users. They
don't understand the way unix works, and they don't want to. They just
want some relatively memorable commands or menus which provide for
their most common needs. pop-11 should provide good support for such
people. (Compare people who want to use pop-11 do do graphics, but do
not want to have to read manuals on the X window system).
I think your suggestions are based on the needs of general software
developers, system managers, etc., rather than the sort of pop11
programmer who occasionally wants to do something from a limited set
of possibilities.
However I agree that it would be good to cater for both.
>
> Ideas for -sysobey/system-
> --------------------------
>
> I'd like to see the following enhancement to -sysobey-, or possibly
> a replacement called -system-. I have made up an optional argument
> syntax which I hope is more or less obvious since this is the kind
> of procedure that cries out for optional arguments in my view.
>
> 1. -system- should be a synonym for -sysobey- or an enhanced version
> of -sysobey-. All C + Perl + UNIX programmers know this command
> by this name and I can see no merit in being different.
I had never heard of "system" till I read your message!
We live in different worlds.
> At the very
> least, the documentation should support programmers looking for it
> by this name.
Sounds reasonable: but that could now be said about a lot of things
in poplog/pop11: people look for them using names which they have
learnt in other contexts.
> 2. It should be possible to explicitly select the shell
> used to execute the command. These days there are rather more
> popular shells than just sh and csh!
As John Williams pointed out, you can do this. However you can't give a
string, like '/bin/bash' as the second argument in
sysobey(string, shell)
> As an aside, we really should consider introducing
> optional argument syntax to do this sort of thing. Here is a
> badly thought-out syntax which I'll use to illustrate some
> ideas throughout the rest of this letter. e.g.
> system[ shell = '/bin/tcsh' ]( 'ls' )
> where the new syntax
> f[ word = <expr>, ... ]
This seems to require f to be a syntax word or macro.
Instead. why not have a convention that such procedures allow a
(possibly empty) list as first argument? (Compare the second
argument of sysexecute, or run_unix_program.)
> introduces a specialisation of "f" with the options of that procedure
> set appropriately. I would also expect that it would be OK to
> write
> f[ foo=a, bar=b ][ gort=c ]
> i.e. that you can cascade optional arg lists.
If f takes a list as first argument then all you need to do is
concatenate the lists.
> 3. It should be possible to capture the result of the command in
> a file/character-repeater/device. (Similarly stderr.)
Agreed. My understanding of run_unix_program is that it allows
you to do that, though you have to be a pop-11 expert as well as a unix
expert to understand the help file.
> 4. It should be possible to supply the command with a standard input
> that is drawn from a file/list/repeater/device.
run_unix_program allows some of these options directly (file, device,
standard input).
I had hoped that using consdevice you can cover ALL the other cases.
Unfortunately when I tried, I got a mishap message
;;; MISHAP - SYSTEM DEVICE NEEDED
it did not accept the result of consdevice as a "system" device.
There should be more direct support for input in the form of a
character repeater (e.g. result of discin). Then other cases, e.g. a
list of characters, or a string, will be easy.
I expect copying some of the code from lib pipeout into run_unix_program
will fix this quite easily.
>
> 3. It should be possible to execute sysobey in the background i.e. there
> should be an optional wait flag
as in run_unix_program.
What is harder is to be able to invoke a program run interactively with
a "line editor" handling the input from the user, and with prompts like
a unix shell (E.g. what ved_imcsh and ved_im try to do and only
partially succeed in doing. I think Roger Evans once wrote something
which generalised them.)
I think that in part what you are saying is not specific to the
pop11/unix interface, but is a *general* point about procedures which
take lots of arguments allowing lots of different combinations. (E.g.
newanyarray, newanyproperty).
In all these cases it would be useful to have a calling syntax which
uses a <keyword>=<value> syntax (as in instance .... endinstance, in
objectclass) so that you don't need to remember or use the precise order
of parameters. (I believe Common Lisp has this.).
Such a facility might be based on a generic procedure calling mechanism,
e.g. a procedure or syntax word called CALL:
CALL(f, [size=xxx, default=yyy, mode=baz....], [-> size=sss, type=ttt])
Then somewhere you could write
define :CALLABLE f;
<specifications for f>
enddefine;
And there would be a language for defining the specification for f
which would be used by CALL to decode the parameter list.
If CALL were a syntax word, there could be an option to do this at
compile time.
Instead of CALL there could be an analogue of "instance ... endinstance"
in objectclass, i.e. invoke ... endinvoke, with lots of key value
arguments, in any order:
invoke f;
kkk1 = vvv1,
kkk2 = vvv2,
kkk3 = vvv3,
endinvoke;
Unspecified arguments would get default values previously specified.
I don't see the point of doing such a thing ONLY for calls between
pop11 and unix utilities. The need is more general. Perhaps that is what
you were saying.
> 5. I would like the default shell of -sysobey- to be explicitly
> changed to /bin/bash (whenever available). It is pretty much
> exclusively used under Linux.
You are assuming dominance of linux, and a particular type of user.
I think changing the default is daft -- it could annoy too many existing
users who will find all sorts of things broken because there's no bash
on their system, or if there is they don't know its syntax. (It's
certainly not available by default on suns, which many people use.)
In any case, having looked at bash (and ksh), I prefer tcsh as my shell.
However there should be an easy way for a system administrator
to set up the default system wide, either via an environment variable
(e.g. $SHELL) or via a system wide init.p, or by the default init.p
files given to new users, which users can change if they wish, or as a
last resort by re-linking.
>
> I would imagine that one of the commonest uses would be
> commands such as
>
> system[ output="repeater", input=my_repeater ]( 'grep -v foo' ) -> rep;
You can already do this sort of thing:
vars outdev;
run_unix_program(
'grep', ;;; unix command
['-v' 'setenv'], ;;; flags/args
sysopen('~/.login', 0, false), ;;; input device
true, ;;; output should be a device
1, ;;; same output device for errors
false) ;;; don't wait
-> ( , outdev, , , ), ;;; ignore other outputs.
vars ddd = discin(outdev);
;;; Then to print the output as it becomes available:
vars char; until (ddd() ->> char) == termin do charout(char) enduntil;
It would be nice if the third (input) argument of run_unix_program
could be an arbitrary pop11 character repeater (e.g. the result of
discin, or stringin).
It should be possible to modify run_unix_program to do this. If
consdevice worked in this context no modification would be needed.
> Shorthand
> ---------
>
> I think that the $( ... ) brackets in /bin/bash are a very
> useful shorthand
I think it is a mistake to import syntactic shorthands from another
language into pop-11. (Propsheet is an example.)
What we need is a comprehensive procedural interface (e.g. extend
run_unix_program to deal with the missing cases). Then groups of users
who so desire can define new macros or syntax forms, or even a new
sub-language (popbash?), allowing well defined transitions between the
languages, such as we already have with prolog, lisp, etc.
We've already had enough problems arising out of the early decision to
use the characters $, % and ! as escapes to the unix shell.
(See pop_charin_escapes)
> Using Environment Variables
> ---------------------------
>
> In addition, there are a variety of UNIX idioms that are very
> common and I believe UNIX versions of Poplog should support. For
> example "$" for accessing environment variables is something that
> I have been using for years in my local library to good effect.
This makes my point. You end up overloading "$". I agree that
it should be possible to use "$" in strings given to procedures that
handle files, unix commands, etc. The ineptly named sysfileok
does the translations, and handles braces. E.g.
sysfileok('${SHELL}')=>
** /bham/bin/tcsh
> One mistake is that my version does not recognise ${foo} as
> identical to $foo.
Wheras syfileok does.
It also handles comma-separated environment variables (not documented):
sysfileok(':$SHELL:$usepop/pop:$popsavelib:')=>
** /bham/bin/tcsh:/bham/common/com/packages/poplog/solaris.current/pop:
/bham/common/com/packages/poplog/solaris.current/pop/lib/psv
> Here's a quick hack that remedies that ...
> ....
> Using this syntax word, you can access and update variables in a
> way that is very natural to UNIX programmers. e.g.
>
> $TERM =>
> ** linux
>
> 'vt100' -> $TERM;
This could easily confuse someone who thought $TERM was a pop11
variable.
What's wrong with this:
define setenv(string1, string2);
string2 -> systranslate(string1)
enddefine;
setenv('TERM', 'vt100');
> Of course, these are just ideas. I would very much like to be able
> to program using these facilities
One of the nice things about pop-11 is that it allows different users to
do these things if they wish. Also you could implement a new language,
and create a saved image which when it starts up runs that language, as
is already done for prolog, lisp, and ml.
But you need to be very careful about building any individual's
favourate shorthand syntax into the language itself.
> - and I definitely would find a
> general and efficient optional argument syntax invaluable.
I agree that there is already a need for that.
We have a local macro ARGS (originally suggested by Brian Logan) which
makes it much easier to write procedures which have optional arguments.
The file is
ftp://ftp.cs.bham.ac.uk/pub/dist/poplog/auto/ARGS.p
and documentation in
ftp://ftp.cs.bham.ac.uk/pub/dist/poplog/help/ARGS
It allows things like this procedure which takes three compulsory
and up to two optional arguments in any order:
define silly(p, q, r) -> result;
;;; set default values for the optional arguments.
lvars A = false, B = 0;
ARGS p, q, r, &OPTIONAL A:isboolean, B:isnumber;
[%p, q, r, A, B%] -> result
enddefine;
The macro could be modified to allow the default arguments
to be specified inline, e.g. something like:
ARGS p, q, r, &OPTIONAL A:isboolean(false), B:isnumber(0);
Aaron
--
Aaron Sloman, ( http://www.cs.bham.ac.uk/~axs/ )
School of Computer Science, The University of Birmingham, B15 2TT, UK
EMAIL A.Sloman AT cs.bham.ac.uk (NB: Anti Spam address)
PAPERS: ftp://ftp.cs.bham.ac.uk/pub/groups/cog_affect/0-INDEX.html
|