From: sns@deimos.caltech.edu (Sam Southard Jr.)
Subject: Re: this newsgroup outside the US.
Organization: Caltech Astronomy Department
Date: Thu, 16 Apr 1992 18:08:13 GMT

In article <1992Apr16.001434.27491@chpc.utexas.edu>, aswx266@chpc.utexas.edu (Michael Lemke) writes:
|> 	The absence of a monitor makes it a little hard to execute 
|> 	commands in a loop for example.  You end up writing command 
|> 	procedures (DCL or Unix) for more or less the same tasks:  Let's
|> 	say you want to subtract the same flat field from ten files or 
|> 	so.  In Unix it's rather simple with `foreach' but in DCL you have
|> 	to write a procedure.  This could be solved if the commands would 
|> 	take wildcards, i.e., in VMS the use of LIB$FIND_FILE would be
|> 	a really good idea.  Or to put it more general:  The commands 
|> 	should take a file specification and not some strange idea of an
|> 	image.

This would be a good idea.  In fact, I think Figaro 3.0 (available on VMS only
right now) has such a mechanism for looping through a command multiple times.
However, for the purposes of discussion, let's assume it doesn't (it may not,
I've not used it), and figure out exactly how it should work.

What you seem to be saying is that something like:

% image @.dst

should display all images in the current directory.  I use the @ sign so as not
to interfere with any shell wildcards - if it interferes, users would always
have to be escaping things, and that gets awkward.

This would be a fairly simple loop, and could be easily implemented now.
However, what about the case where you have an output file?  For example, an
obvious extension of the above method would be:

% icmult IMAGE=@.dst OUTPUT=o@.dst

which would multiply all images in the current directory by some number and
place the output in the file o123.dst (if the original file was 123.dst).

However, do you really want such a restriction?  Shouldn't you be able to call
the output file anything you like?  Perhaps an interface like:

% icmult IMAGE@="123 456 789" OUTPUT@="abc def ghi"

would be better.  Or perhaps something like:

% icmult IMAGE@ 123 456 789 @IMAGE OUTPUT@ abc def ghi @OUTPUT

The second method gets around the problem of specifying multiple strings (for
plot labels, perhaps), but is a bit wordy.  It would also allow the user to
use the normal shell wildcards, which is a big plus.

Does anyone have an alternative method?

No matter what, if the parameter is supposed to be a file name, it should
probably have the .dst extension stripped away.  I'm sure just about every
Figaro user has been annoyed by doing something like 'istat foo.dst' and it
coming back with "The file foo.dst.dst does not exist".

|> 	You also quite often end up writing lots of FORTRAN modifying 
|> 	little things in existing commands.  I also find myself reading 
|> 	the sources quite too frequently just to figure out what they 
|> 	are doing at all.  I'd like to have the help (VMS) not that 
|> 	verbose.  It's nice if you see the system for the first time but
|> 	if you are looking for a command it's pretty bad.  And 
|> 	eventually you just end up in the FORTRAN source comments.

OK, what should be removed from the help system?  How should it be changed?

|> The commands should be more graphic oriented like the IRAF splot for
|> example.  Unless you use the new `figdisp' on a workstation it's a real
|> pain to look through individual rows or columns in an image for
|> example.  The huge sharable images on VMS make image activation very
|> slow.  So a sequence extracting a row and displaying it to `step
|> through' an image takes ages.

The answer to that is really a non-answer.  The vast majority of figaro sites
are gradually moving to SunOS (with a few going to other types of graphics
workstations, such as DECstations).  This means that Unix and X are going to be
dominant.  Since figdisp is the only supported X interface, saying that it
works everywhere except where you use figdisp is basically saying it works
everywhere.

However, you could also mean that you'd like more interactive, graphically
oriented, commands.

|> Btw, for VMS I wrote something that uses the callable FIGARO interface
|> so that everything runs in a background subprocess.  That process is
|> activated only once.  From the user everything looks as before but the
|> commands are executed *much* faster.  But this is interesting only for
|> the VMS version of FIGARO.

Yes, and the percentage of sites running VMS Figaro is destined to decrease.

|> Why not create a single command to do image arithmetic instead of IADD, 
|> ISUB, IDIV, IMULT, ICADD, ICDIV.....  A general LET would do:
|> 
|> $ MLET result.z.data = (obs.z.data - bias.z.data)/(ff.z.data)

This seems to be a very good idea.  Would you limit it to +-*/?  If not, what
else should be included.  Anyone care to volunteer to write a simple parser?

-- 

Sam Southard, Jr.
{sns@deimos.caltech.edu|{backbone}!cit-vax!deimos!sns}