edwin@hcr.UUCP (Edwin Hoogerbeets) (08/19/88)
In article <1877@iscuva.ISCS.COM> ricks@iscuva.UUCP writes: [funky stuff deleted] >Steve and/or Matt ... while adding real pipes and all those other goodies ^^^^^ ^^^^ Or Johan... >I'm sure you are working on <grin> you might give some thought to adding >some way for a child process to inherit csh's environment! If there is >any interest, I will post the diffs for my rather trivial path mods. Your idea about the system() call sounds quite interesting! I'd be interested in seeing/using it when you are done. Comment: If the shell were to be changed to inherit the environment, please use Manx "set" style environment vars. (sounds like a type of yoghourt, eh?) I think this is what they are going to be using in 1.3 and 1.4 and this would be an easy way of exporting the environment while remaining upwardly compatible. ------ --------- = ------------------------------------------- Edwin (Deepthot) Waterloo co-op student, HCR Corporation Hoogerbeets 2A computer science and psychology uunet!utai!utcsri!hcr!edwin Me Tarzan, Unix. edwin@hcr // Freudian slips? This message or: // contains no Freudian sex. ...!hcr!MsgPort!edwin \\ // Amiga Everyone is entitled A B2000 running UUPC \X/ Enthusiast to my own opinion!
jesup@cbmvax.UUCP (Randell Jesup) (08/21/88)
In article <3816@hcr.UUCP> edwin@hcrvax.UUCP (Edwin Hoogerbeets) writes: > >Comment: If the shell were to be changed to inherit the environment, >please use Manx "set" style environment vars. (sounds like a type of >yoghourt, eh?) I think this is what they are going to be using in 1.3 and >1.4 and this would be an easy way of exporting the environment while >remaining upwardly compatible. Just to correct a misconception, Manx env vars are NOT compatible with 1.3 ENV: vars. 1.3 Env vars are stored in a filesystem, usually ram:, but it could be assigned anywhere. To access and env var, merely do an Open("Env:varname",MODE_OLDFILE) and if it exists read it in. The Manx env vars are stored in a fake library (no entry points, just a placeholder so it can be found), with a pointer to a contiguous block of memory storing all the env vars. Any time a var is changed or added, it has to allocate a new hunk of memory for all the vars, make a new list of them, and free the old one. Jim Goodnow may be modifying Manx C to allow use of 1.3 env vars (I'd be suprised if he didn't). -- Randell Jesup, Commodore Engineering {uunet|rutgers|allegra}!cbmvax!jesup
ncreed@ndsuvax.UUCP (Walter Reed) (08/23/88)
In article <3816@hcr.UUCP> edwin@hcrvax.UUCP (Edwin Hoogerbeets) writes: >Comment: If the shell were to be changed to inherit the environment, >please use Manx "set" style environment vars. (sounds like a type of >yoghourt, eh?) I think this is what they are going to be using in 1.3 and >1.4 and this would be an easy way of exporting the environment while >remaining upwardly compatible. Um, no. 1.3 uses a totally different method. They have an ENV: device which for now is just a logical Assign to a directory. Each variable is a file, with a name of the environment variable. Since environment variables are files, think of the info that could be stored in them! much more versitile than normal Manx/Arp style variables. One could write a program that could look at the manx style variables and convert them to 1.3 style ones and visa versa. It could run once every 10 seconds or so... BTW, I have a shared functions library that has 1.3 compatible getenv and setenv among other things. As soon as I get the bugs out I will be making it available. It has bindings for both compilers. -- ------ Walter Reed ------ + uunet!ndsuvax!ncreed or ncreed@ndsuvax.BITNET "There's no point in being + or ncreed@plains.NoDak.edu grown up if you can't be + childish sometimes!" Dr. Who + USnAIL: 925 9th Ave W. West Fargo, ND 58078