Re: CGP/1.0 specification

robm@ncsa.uiuc.edu (Rob McCool)
Message-id: <9311180924.AA12114@void.ncsa.uiuc.edu>
From: robm@ncsa.uiuc.edu (Rob McCool)
Date: Thu, 18 Nov 1993 03:24:08 -0600
In-Reply-To: hoesel@chem.rug.nl (frans van hoesel)
       "Re: CGP/1.0 specification" (Nov 18,  9:27am)
X-Mailer: Mail User's Shell (7.2.5 10/14/92)
To: hoesel@chem.rug.nl (frans van hoesel)
Subject: Re: CGP/1.0 specification
Cc: www-talk@nxoc01.cern.ch

/*
 * Re: CGP/1.0 specification  by frans van hoesel (hoesel@chem.rug.nl)
 *    written on Nov 18,  9:27am.
 *
 * > *** Environment Variables
 * > 
 * > To pass most data from the server to the scripts, I propose we use
 * > environment variables.  This way, we escape command line length
 * > restrictions, and complications of short scripts having to parse stdin.
 * 
 * maybe I missed part of this discussion, but why not send this data all
 * to stdin. If simple scripts need this info as environment variables
 * then they do need to call a (standard) subroutine to read the environment.
 * 
 * If you would supply the data on stdin (perhaps just the same list as you
 * use below, endig with a special mark (which could be as simple as the
 * first blank line, for very simple scripts)) then people who would
 * need this infi will simply call onathore not-so-standard subroutine
 * to parse this info from stdin. You could supply this not-so-standard
 * routine for them.

Shell scripts would still have a difficult time with this. C programs would
have no problem.

 * I got interested, because you stated that environment variables would not
 * have limits. 
 * First of all, your proposol does have limits, because I cannot have many
 * queries. This is because you still can have a lot of arguments.

I don't understand. Can you restate this? What do you mean by "cannot have
many queries"?

 * Secondly to test if environment is unlimited in length 
 * I did
 * setenv TEST `ls -l`
 * on a 450 file directory. That took an extremly long time in tcsh (an 
 * equivalent for csh). You might try this to see how long it takes!

I did. I could not get Sun's version of csh to do that, it would complain
about too many words. Our version of csh requires that the second argument
to setenv be a word or quoted string.

I tried your example in zsh, with a 78K file instead of a large directory
listing. Setting an environment variable equal to the contents of this file
took just under 3 seconds on an unloaded sun 4. A little slower than I'd
like, but not bad.

 * So using environment isn't very efficient.

...... I don't think I can agree with your conclusion given your evidence,
sorry.

 * secondly 
 * printenv failed after I had set this variable.
 * everything came back ok after I removed this variable.
 * So even environment variable might have problems with long queries.
 * (I say might, because printenv could be broken or whatever)

Sounds to me like csh is broken. zsh handled the 78K environment variable
with flying colors. From the implementation of the library call putenv,
also, I see no reason why environment variables would be limited. Is there
something I'm missing?

 * 'm not really against environment variable, but the very long time it
 * took to set the above environment did scare me a bit, and I really don't see
 * the point in using them at all. (eg I don;t see the reason you cannot use
 * a special purpose routine for parsing stdin, and for very simple
 * scripts it can be as sinple as skipping to the first blank line). But as Is
 * said, I may have missed part of the discussion.
 */

But it's not that simple. I have no problem with the stdin based approach
for C programs and PERL scripts, but shell scripts are another matter
entirely. 

--Rob