maart@cs.vu.nl (Maarten Litmaath) (05/06/89)
Kemp@DOCKMASTER.NCSC.MIL writes:
\...
\ /home/orion/jsmith/projectA/speech
\ /home/magellan/tjones/lib/splib.a
\With logical names, I could define the first as "joe" and the second as
\"splib", and do things like:
\ cd joe
\ ls joe
\ ar t splib
\ cc myprog -lsplib
Bourne shell:
joe=/home/orion/jsmith/projectA/speech
cd $joe
etc.
--
"If it isn't aesthetically pleasing, |Maarten Litmaath @ VU Amsterdam:
it's probably wrong." (jim@bilpin) |maart@cs.vu.nl, mcvax!botter!maartd.jba@harald.ruc.dk (Jan B. Andersen) (05/07/89)
I have been following the discussion on LOGICALS vs ENVIRONMENT with interest. It's true that you can achieve the same with both methods, but environment variables requires a bit work than logicals. As jeffrey@algor2.UUCP (Jeffrey Kegler) writes: >Briefly, a formal file name is >a name by which the program interfaces with a JCL (or shell) language and >which can be redefined. UNIX has 3 usable ones, stdin, stdout and stderr, >and that covers a remarkable variety of situations. But an application >might well want one or two databases, an transaction input file, an error >output, a logging file and 2 or 3 reports. It would be nice if each of >these could be redirected as easily as stdin, stdout and stderr. One thing which I haven't seen mentioned in the discussion is how to extend stdin and stdout with something like stddata[] and stdlist[]. As I understand it, it's the shell which handles io-redirection etc. and sets up stdin, stdout and stderr before forking the process. Now, instead of modifying the shell to handle stddata and stdlist, why not having a special io-shell do the extra work involved in opening stddata[] and stdlist[]. Assume the following enviroment variables: STDDATA="db1 db2 my-transactions" STDLIST="/dev/conslog /dev/tape |lp" With the proposed io-shell the job might be started with: $ io-shell my-job The io-shell would then open db1, db2, my-transactions for input, /dev/conslog and /dev/tape for writing, and fork lp with input coming from a pipe and these file-descriptors could then be passed to my-job just like stdin, stdout and stderr. Is there any thing wrong with this idea? --- -- Jan B. Andersen, Datalogi 19.1 | IfUmust: +45 46 75 77 11 /^^^\ Roskilde Universitetscenter | .---------------------------. { o_o } Postbox 260, | ( "SIMULA does it with CLASS" )<-- \ o / DK-4000 Roskilde (Denmark) | `---------------------------' -mm--mm-
gph@hpsemc.HP.COM (Paul Houtz) (05/08/89)
chris@mimsy.UUCP (Chris Torek) writes: >In article <19472@adm.BRL.MIL> Kemp@DOCKMASTER.NCSC.MIL writes: >[more `Unix is deficient' blather] >-Say there are a few of my friends' directories and files that are of >-general interest: >- >- /home/orion/jsmith/projectA/speech >- /home/magellan/tjones/lib/splib.a >- >-With logical names, I could define the first as "joe" and the second as >-"splib", and do things like: >- >- cd joe >- ls joe >- ar t splib >- cc myprog -lsplib Now Torek says just do this: >$ joe=/home/orion/jsmith/projectA/speech >$ splib=/home/magellan/tjones/lib/splib.a >$ cd $joe >$ ls $joe >$ ar t $splib >$ cc args -l$splib Okay, now I run my program that refers directly to 'speech' in an OPEN statement. OOOPS! wrong directory.
ghe@nucthy.physics.orst.edu (Guangliang He) (05/09/89)
In article <810049@hpsemc.HP.COM> gph@hpsemc.HP.COM (Paul Houtz) writes: =chris@mimsy.UUCP (Chris Torek) writes: = =>In article <19472@adm.BRL.MIL> Kemp@DOCKMASTER.NCSC.MIL writes: =>[more `Unix is deficient' blather] =>-Say there are a few of my friends' directories and files that are of =>-general interest: =>- =>- /home/orion/jsmith/projectA/speech =>- /home/magellan/tjones/lib/splib.a =>- =>-With logical names, I could define the first as "joe" and the second as =>-"splib", and do things like: =>- =>- cd joe =>- ls joe =>- ar t splib =>- cc myprog -lsplib = =Now Torek says just do this: = =>$ joe=/home/orion/jsmith/projectA/speech =>$ splib=/home/magellan/tjones/lib/splib.a =>$ cd $joe =>$ ls $joe =>$ ar t $splib =>$ cc args -l$splib = = Okay, now I run my program that refers directly to 'speech' in an =OPEN statement. OOOPS! wrong directory. Ok, put the line joe=/home/orion/jsmith/projectA/speech on the begining of your program, problem solved!!! ----------------------------------------------------------------------- | USMAIL: Guangliang He | INTERNET: ghe@PHYSICS.ORST.EDU Department of Physics | ghe@jacobs.CS.ORST.EDU Oregon State University | BITNET: hegl@orstvm.bitnet Corvallis, OR 97331 | PHONE: (503) 754-4631 | -----------------------------------------------------------------------
gandalf@csli.Stanford.EDU (Juergen Wagner) (05/10/89)
Many UNIX systems support symbolic links, and that seems to be what we need to implement system-independent file system structures. Symbolic links are anchored in the file system, i.e. there is a pathname associated with them. Programs should never refer to constant locations of files unless they can be sure the respective files are always where they are supposed to be. In all other cases, environment variables, command line arguments, or special directives are a much better way of handling such differences. With symbolic links, you get even more flexibility: your program can happily refer to files wherever it wants, you only have to make sure that the links point to the right files. This allows static naming a la FORTRAN (5 for input, 6 for output if I remember that correctly) :-). The desirable feature of not having global assignments to logical names (= symbolic links) but to be able to change them from process to process can be accomplished by using environment variables. It seems to me that passing textual (uninterpreted) information through environment variables, and leaving their interpretation to applications, is a cleaner way of handling this subject than enforcing a single semantics all the time. -- Juergen Wagner gandalf@csli.stanford.edu wagner@arisia.xerox.com
chris@mimsy.UUCP (Chris Torek) (05/10/89)
In an article whose referent was deleted by faulty news software, I suggested using some of the shell's capabilities for abbreviations: >>$ joe=/home/orion/jsmith/projectA/speech >>$ cd $joe >>$ ls $joe In article <810049@hpsemc.HP.COM> gph@hpsemc.HP.COM (Paul Houtz) writes: > Okay, now I run my program that refers directly to 'speech' in an >OPEN statement. OOOPS! wrong directory. Apparently he prefers the sort of behaviour exemplifed by the following posting (taken directly from comp.os.vms/info-vax): [article <890424131552.2040069d@UWYO.BITNET>, from jimkirk@OUTLAW.UWYO.EDU] >What pointed this out was my attempt to compile a Fortran program named MP, >when the command "FORT MP" blew up because it could not find MP_8NN. I can >work around with "FORT MP.FOR", but why is MP system-wide? This is why the shells (and the editors---both vi and Emacs [GNU *and* Unipress] expand environment variables in file names) use a bit of syntax to enable variable expansion. Apparently once someone else has defined `speech' in VMS, you cannot get rid of it. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
usenet@cps3xx.UUCP (Usenet file owner) (05/11/89)
In article <17410@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes: >Apparently he prefers the sort of behaviour exemplifed by the following >posting (taken directly from comp.os.vms/info-vax): > >[article <890424131552.2040069d@UWYO.BITNET>, from jimkirk@OUTLAW.UWYO.EDU] >>What pointed this out was my attempt to compile a Fortran program named MP, >>when the command "FORT MP" blew up because it could not find MP_8NN. I can >>work around with "FORT MP.FOR", but why is MP system-wide? > >This is why the shells (and the editors---both vi and Emacs [GNU >*and* Unipress] expand environment variables in file names) use a >bit of syntax to enable variable expansion. Apparently once someone >else has defined `speech' in VMS, you cannot get rid of it. Not quite. Just to clear things up: 1. DEC screwed up when they made MP system-wide. Most system-wide logical names use the "$" (a character reserved for DEC's use) in their name. For instance, SYS$SYSTEM is the equivalent of "/bin". 2. There are four kinds of logical names (actually you can make more, but these are the main ones): process, job, group, and system. A process logical name is similar to an environment variable. A job logical name is shared between all processes that are part of a session (i.e., the ones which share a control terminal in UNIX terminology, more or less). It takes privilege to create group or system-wide logical names. I like environment variables. I also like logical names. +---------------------------+------------------------+-------------------+ | Anton Rang (grad student) | "VMS Forever!" | VOTE on | | Michigan State University | rang@cpswh.cps.msu.edu | rec.music.newage! | +---------------------------+------------------------+-------------------+ | Send votes for/against rec.music.newage to "rang@cpswh.cps.msu.edu". | +---------------------------+------------------------+-------------------+
mike@yunexus.yorku.ca (Mike Marques) (05/12/89)
In article <17410@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes: > Apparently he prefers the sort of behaviour exemplifed by the following > posting (taken directly from comp.os.vms/info-vax): > > [article <890424131552.2040069d@UWYO.BITNET>, from jimkirk@OUTLAW.UWYO.EDU] > >What pointed this out was my attempt to compile a Fortran program named MP, > >when the command "FORT MP" blew up because it could not find MP_8NN. I can > >work around with "FORT MP.FOR", but why is MP system-wide? > > This is why the shells (and the editors---both vi and Emacs [GNU > *and* Unipress] expand environment variables in file names) use a > bit of syntax to enable variable expansion. Apparently once someone > else has defined `speech' in VMS, you cannot get rid of it. > -- > In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) > Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris > However that someone else has to be a system manager or someone with similar privileges (you might know this). Someone's logical names are put in their own private logical name table. There are also system wide logical name tables and group wide name tables, etc. This is something I miss on Unix (I do work on both OSs). Under VMS I can define TEXINPUTS, for instance, in the system wide logical name table and when somebody uses tex things will work. Under UNIX you can't transparently (I could be wrong) set things up for a user so that he can do this. And don't tell me you just have to tell the user about setenv or whatever, not all users want to know a lot of details about computers. Of course Unix was not designed for those users but that's a different discussion. I just happen to think the way logical names are handled under VMS to be more of a benefit than an impairment and would like to see some similar system under Unix. And defining SPEECH in the system wide table is a sign of unthinking system personnel, make it SYS_SPEECH if you must have it. Mike disclaimer: I never said that. -- Mike Marques | Usenet: ......!utzoo!yunexus!mike York University (Computing Services) | mike@nexus.yorku.ca -------------------------------------| Bitnet: mike@libra.yorku.ca Only visiting this planet... | Voice: (416) 736-5257
jay@silence.princeton.nj.us (Jay Plett) (05/12/89)
In article <MIKE.89May11142510@yunexus.yorku.ca>, mike@yunexus.yorku.ca (Mike Marques) writes: > ... Under VMS I can > define TEXINPUTS, for instance, in the system wide logical name table > and when somebody uses tex things will work. Under UNIX you can't > transparently (I could be wrong) set things up for a user so that he > can do this. And don't tell me you just have to tell the user about setenv > or whatever, not all users want to know a lot of details about computers. In the skeleton .login that is installed in a new user's home directory: source /usr/local/lib/dotlogin In /usr/local/lib/dotlogin: setenv TEXINPUTS /wherever/it/is/this/month You need tell the naive user nothing. The slightly sophisticated user will edit h{is,er} .login, adding things before and after the "source" (according as they want their environment superseded by the system administrator's). The more sophisticated user is free to throw out the "source" and create a private universe. > Of course Unix was not designed for those users but that's a different > discussion. No, it's the same discussion. See above. Unix gives you the rope to design your own noose. jay@princeton.edu