Recent Changes - Search:



Alpha and Unix

Main.AlphaAndUnix History

Hide minor edits - Show changes to markup

October 16, 2007, at 03:49 PM by agm - spam cleanup
Deleted line 0:


October 16, 2007, at 03:01 PM by -
Added line 1:


January 29, 2006, at 02:37 PM by -
Changed line 16 from:

These pages were started by JK? who is still a beginner in


These pages were started by JK who is still a beginner in

January 29, 2006, at 02:33 PM by -
Changed line 16 from:

These pages were started by Joachim Kock (JK) who is still a beginner in


These pages were started by JK? who is still a beginner in

Changed line 124 from:
    set F [maxima expand( $F )]
    set F [maxima expand( $F )]
January 23, 2006, at 09:07 PM by -
Changed line 161 from:

'<JK 20/09/2003>'


<JK 20/09/2003>

January 23, 2006, at 09:06 PM by -
Added lines 1-161:

(:title Alpha and Unix:)

Some general considerations about Alpha's interaction with unix programmes. The subjects outlined here are treated in more depth on the pages Pipes.PipesAndShellLikeInteraction , Pipes.BatchLikeInteractionViaPipes , Pipes.Worksheets , Pipes.StepConsoles , Pipes.ErrorPipesAndWindowPipes , Pipes.InteractionWithTexUnderUnix , Features.SpellChecking , Pipes.Paths , and finally [ProposedInterfaceToPipes].

These pages were started by Joachim Kock (JK) who is still a beginner in this whole unix business --- please insert corrections and comments throughout as you see necessary, but please mark them clearly with your initials.


Under OS9, Alpha communicated with other applications through Apple Events. With AlphaX and AlphaTk under OSX a whole new host of interaction possibilities is available, namely interaction with text-based unix programmes, through pipes and sockets. During the first six months of public AlphaX, a lot of experiments have been carried out, but there is still a long way to go before the different techniques and approaches crystalise into stable interfaces for all interactions. Eventually Alpha will become THE interface to most text based unix applications under OSX, just like our great example emacs...

At the same time, Apple Events work just like on OS9 and they continue to be the preferred way of interaction with all GUI applications (e.g., Eudora, iTunes, OzTeX...)

This page is meant to collect some basic techniques, describe some approaches, and outline some visions, with the hope that a more general picture will emerge.


The simplest example of unix interaction is through the Tcl command exec, which was disabled in OS9 versions of Tcl. In AlphaX you can do things like this in the shell (Cmd-Y):

     exec ps axc | grep Alpha
     6178  ??  S    868:27.95 AlphaX

     exec find /Users/joachim -type f -iname cookies*
    /Users/joachim/Library/Application Support/Chimera/Profiles/default/jklif4xi.slt/cookies.txt

     exec kpsewhich diagrams

In these examples, a single question is given and a simple answer is returned. Things get more interesting when trying to integrate with unix applications where two-way communication is required, or where the result of a command is not a static string but something that prints to the screen in a dynamic way. The archetypic example of two-way communication is a shell (say bash or tcsh); perhaps more interesting examples are math applications (like Maxima, Yacas, Macaulay2,...), statistics software (SAS, R, etc), or a database like MySQL. There are many reasons why you would want to run such programmes from within Alpha, the main point is of course the editing capacities, all your personal keyboard shortcuts and completions --- it is simply much more comfortable to stay inside Alpha than changing to some other application. Another reason is that one place where you are likely to need the data output from some application is when you are writing about these data, and of course you do your writing in Alpha, and of course it is convenient to pipe the output directly into a window in Alpha, right where you need it.

But since Alpha is so easy to programme, you might go further and so-to-speak write a new user interface to some of these programmes, transforming the output from the programme and filtering the input strings before they are sent.

These are the two extreme scenarios: shell-like interaction and worksheets.


In shell-like interaction, the input and output are transferred raw, so the experience is like running the programme in the terminal, except that now it takes place in an Alpha window. So all keystrokes are sent directly to the external programme, and all its output is written directly to the shell-like window in Alpha dedicated to the interaction.


In the other extreme, the notion of worksheets is illustrative: suppose there is a math programme (say Maxima) running in the background as a sort of server; Alpha has a connection to this server and can ask it to evaluate commands. (The math programme runs continuously, preserving the state.) Imagine for example you are writing some latex document with a lot of linear algebra, and you need to perform several operations on a matrix and type the intermediate results. Instead of switching to your math programme do the computation, copy the result, switch back to Alpha, paste it in, you would stay inside your tex document, type the appropriate Maxima command in a special-purpose region of your tex document, and press some key binding that evaluates the code remotely in the Maxima server session and inserts the result just below the instruction. Next you can perform the next operation, taking advantage of the fact that the remote programme still retains the values of the variables used in the first calculation. The idea is to have a sort of single master worksheet with LaTeX and Maxima code interwoven.


Somewhat in between the two extremes there is another obvious concept of interaction which is actually a prerequisite for implementing worksheets: it is simply the possibility of remote evaluation of expressions. It is just like exec, except that the remote execution can take place in any programme --- like Maxima, just to keep this example. Clearly this is needed for worksheets, but it can also be useful in non-interactive situations like in Tcl programmes: in the middle of a Tcl programme where you have some string F equal to "(x-y)^3" you can send it to maxima to have it expanded with some command like

    set F [maxima expand( $F )]

which will set F to the string "-y^3+3*x*y^2-3*x^2*y+x^3". For one thing, this allows you to write math scripts in Tcl! --- and such scripts can be powered by any number of specialised math programmes.


Interaction with TeX is perhaps one of the most important outward features in Alpha. It is not difficult to establish this interaction (cf. the interaction provided in the standard distribution), but there is room for many refinements (cf. for example tetexComm).


The state-of-the-art unix spellchecker is aspell, and Alpha interacts very well with it. In the AlphaTcl distribution there is already support for spellchecking a whole document. Perhaps there is room for improvements with respect to interaction also with aspell dictionaries (user dictionary and corrections database), but it might actually already be in place --- not too sure.

There is an experimental check-as-you-type spellchecker (also using aspell) which uses Alpha's hypertext facilities. This is still a rough prototype, but the core functionality seems to work alright.


Getting paths right is a general problem when interacting with unix programmes (and a problem in unix itself, it seems). Some remarks from Alpha-D have been collected on a page dedicated to Paths.

'<JK 20/09/2003>'

Page last modified on October 16, 2007, at 03:49 PM
Hosted on Logo