gph@hpsemc.HP.COM (Paul Houtz) (05/03/89)
gph@hpsemc.HP.COM (Paul Houtz) / 10:37 am Apr 18, 1989 / I wrote: > I am interested in peoples opinions of deficiencies or problems with >unix. Please send me e-mail or post here. I would be happy to post >a summary. Oh, I really should incude an example so one can get the idea of whata I mean: One thing I would categorize as a deficiency is the UNIX file system's inability to span disc drives. In otherwords, your file system is limited to the size of a disc drive. If you want more files in that file system, you must re-create it on a larger disc drive, or, if you already have the largest available, you must start putting files in multiple file systems. To correct this: Allow the disc address to be part of the address of the file, this way, you would only need one file system per Unix system, and that file system would have as many drives as it needs. It would simplify matters greatly. Paul Houtz HP Technology Access Center 10670 N. Tantau Avenue Cupertino, Ca 95014 (408) 725-3864 hplabs!hpda!hpsemc!gph gph%hpsemc@hplabs.HP.COM
rec@dg.dg.com (Robert Cousins) (05/03/89)
In article <810046@hpsemc.HP.COM> gph@hpsemc.HP.COM (Paul Houtz) writes: >gph@hpsemc.HP.COM (Paul Houtz) / 10:37 am Apr 18, 1989 / > >I wrote: >> I am interested in peoples opinions of deficiencies or problems with >>unix. . . . > One thing I would categorize as a deficiency is the UNIX file system's >inability to span disc drives. In otherwords, your file system is limited >to the size of a disc drive. If you want more files in that file system, >you must re-create it on a larger disc drive, or, if you already have the >largest available, you must start putting files in multiple file systems. > To correct this: Allow the disc address to be part of the address of >the file, this way, you would only need one file system per Unix system, >and that file system would have as many drives as it needs. It would >simplify matters greatly. DG/UX version 4.x has this improvement already. Specifically, file systms are made up of logical pieces which can be on any number of devices and can be dynamically added. If you run out of space, just add another piece from some available device on the system. Furthermore, the block arithmetic is done in 48 bits so that you can support VERY large file systems. The real problem with hugh file systems is that it is so easy to have them corrupted. The solution is for the file system to duplicate the allocation information in system related blocks so that a file system rebuild can be done quickly and easily with little or no loss of information. THis info should contain a time stamp for added dependability. This is what DG/UX does. >Paul Houtz >HP Technology Access Center Robert Cousins Dept. Mgr, Workstation Dev't Speaking for myself alone.
guy@auspex.auspex.com (Guy Harris) (05/04/89)
> One thing I would categorize as a deficiency is the UNIX file system's >inability to span disc drives. In otherwords, your file system is limited >to the size of a disc drive. Some UNIX systems (Pyramid is one of them, I think) allow you to create a pseudo-partition that spans multiple disk drives, which allows you to put a vanilla UNIX file system on more than one drive. > To correct this: Allow the disc address to be part of the address of >the file, Huh? What do you mean by "the disc address" or "the address of the file" - especially the latter? If you mean "the *name* of the file", well, I'm just as glad that the name of the disk is *not* part of the name of the file. If you mean the i-number of the file, for example, the pseudo-partition scheme mentioned above can probably achieve the same goal without whacking on the file system.
dg@lakart.UUCP (David Goodenough) (05/04/89)
gph@hpsemc.HP.COM (Paul Houtz) sez: > I wrote: >> I am interested in peoples opinions of deficiencies or problems with >>unix. Please send me e-mail or post here. I would be happy to post >>a summary. > > Oh, I really should incude an example so one can get the idea of whata > I mean: > > One thing I would categorize as a deficiency is the UNIX file system's > inability to span disc drives. In otherwords, your file system is limited > to the size of a disc drive. If you want more files in that file system, > you must re-create it on a larger disc drive, or, if you already have the > largest available, you must start putting files in multiple file systems. Huh??? 'We have the technology, we have the capability, to create the world's first bionic "span-partition"'. We have an ISI V24 (68020 machine) with a pair of Northern Telecom 269 MB drives, and I have been tempted for a long time to change the three "work" partitons (/u1 /u2 /usr) into one big span partition - I could probably do this in about five minutes, the instructions in the manual say that it's trivial. It just so happens that /usr and /u1 live on sm0, and /u2 lives on sm2, so I'd have a partition spanning two separate disk drives. Of course this may be a nice feature added by the ISI people, like the ttyd? hack that when you call a terminal ttyd? (our modem line is ttydx), all the necessary programs (getty, uucico, tip, etc.) know that it is a bidirectional modem line, and behave sensibly. -- dg@lakart.UUCP - David Goodenough +---+ IHS | +-+-+ ....... !harvard!xait!lakart!dg +-+-+ | AKA: dg%lakart.uucp@xait.xerox.com +---+
Kemp@DOCKMASTER.NCSC.MIL (05/05/89)
There has been the continuing debate here about the lack of VMS style logical names under Unix, with most of the Unix people saying: "Use environment variables and/or symbolic links". Well, that doesn't hack it even for those of us that DON'T have billions of lines of COBOL to maintain. 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 as well as writing application programs that use them. Environment variables won't work unless you rewrite all your applications AND ALL UNIX APPLICATIONS to do a getenv before every open (figure the odds!). Symbolic links won't work for obvious reasons (they are global, users would have to have write permission on root, they clutter up the file system with permanent objects that really should be temporary, etc.). Eduardo Krell of AT&T reports in Sun-spots v7n262 that Apollo's Unix allows environment variable substitution inside symbolic links. The example is /usr/$(SYSTYPE)/bin, which allows users to select the flavor of Unix they wish to run. This is a step in the right direction, but Unix is still deficient until it allows uniformly applied user-local abbreviations for arbitrary locations in the filesystem name space. Dave Kemp <Kemp@dockmaster.ncsc.mil>
hardy@rb-dc1.UUCP (Jeff Hardy) (05/06/89)
Actually there is no restriction in UNIX that a filesystem reside on one disk. By convention it has been done this way. The interface between UNIX and its devices is through the [cb]devsw arrays. One could quite easily write a pseudo-driver that had a single entry and actually used several disks to implement it. You do NOT want to put any disk addresses in the file system. There are however restrictions imposed on the sizes of the filesystems or number of inodes due to the sizes of the variables that hold this information. Jeff Hardy
chris@mimsy.UUCP (Chris Torek) (05/06/89)
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
$ joe=/home/orion/jsmith/projectA/speech
$ splib=/home/magellan/tjones/lib/splib.a
$ cd $joe
$ ls $joe
$ ar t $splib
$ cc args -l$splib
-... Environment variables won't work unless you rewrite all your
-applications AND ALL UNIX APPLICATIONS to do a getenv before every
-open (figure the odds!).
That is not what they are for. Environments are for *specific*
tasks---$PATH for executables, $TEXINPUTS for TeX macros, and so
forth.
--
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chrisjeffrey@algor2.UUCP (Jeffrey Kegler) (05/06/89)
In article <810046@hpsemc.HP.COM> gph@hpsemc.HP.COM (Paul Houtz) writes: >gph@hpsemc.HP.COM (Paul Houtz) / 10:37 am Apr 18, 1989 / > >I wrote: > I am interested in peoples opinions of deficiencies or problems with >unix. . . . I miss very little from the IBM world, but the availability of formal file names is one of them. Once UNIX starts getting into commercial environments they will become more useful. 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. Of course, your programs could always look for environment variables, and if present, attempt to open their value as a file. -- Jeffrey Kegler, President, Algorists, jeffrey@algor2.UU.NET or uunet!algor2!jeffrey 1762 Wainwright DR, Reston VA 22090
barmar@think.COM (Barry Margolin) (05/06/89)
In article <17327@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes: Describing how to use shell variables as a substitute for logical file names: >$ joe=/home/orion/jsmith/projectA/speech >$ splib=/home/magellan/tjones/lib/splib.a >$ cd $joe >$ ls $joe >$ ar t $splib >$ cc args -l$splib That's fine if the file name is passed in on the command line. But what if a program prompts for a file name? For instance, when specifying files in an editor's read or write command. On Multics, my solution to this would have been to take advantage of dynamic linking. All Multics programs that take file names must call expand_pathname_ to parse a pathname into an absolute directory pathname and a directory entry name. It's a simple matter to place a personalized version ahead of the standard one in one's linker search path (in fact, I did just this, although not for the above use, although I know people who did the above). Now SunOS has dynamic linking, so perhaps open(2), chdir(2), etc., could be replaced this way; however, programs don't have to be dynamically linked, so you would end up with a situation where logical file names are recognized by some commands and not by others, depending only on how they were built. Also, this would have problems if shell wildcard expansion returned a name that happened to match a logical name (wildcards should generally be processed AFTER expanding logicals). Barry Margolin Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
scott@dtscp1.UUCP (Scott Barman) (05/07/89)
In article <424@algor2.UUCP> jeffrey@algor2.UUCP (Jeffrey Kegler) writes: >In article <810046@hpsemc.HP.COM> gph@hpsemc.HP.COM (Paul Houtz) writes: >>gph@hpsemc.HP.COM (Paul Houtz) / 10:37 am Apr 18, 1989 / >> >>I wrote: >> I am interested in peoples opinions of deficiencies or problems with >>unix. . . . > >I miss very little from the IBM world, but the availability of formal file >names is one of them. Once UNIX starts getting into commercial >environments they will become more useful. 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 Is this anything like trying to remember which utilities wants their input from ddname SYSUT1 or SYSIN? Or ourput to SYSOUT or SYSPRINT or even SYSUT2? I do not miss anything from that world!!!! -- scott barman {gatech, emory}!dtscp1!scott
mjs@mentor.cc.purdue.edu (Mike Spitzer) (05/07/89)
In article <424@algor2.UUCP> jeffrey@algor2.UUCP (Jeffrey Kegler) writes: >I miss very little from the IBM world, but the availability of formal file >names is one of them. Once UNIX starts getting into commercial >environments they will become more useful. 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. The Bourne shell and other reasonably sh-compatatible shells (like ksh) allow the redirection of any file descriptor, not just stdin, stdout, and stderr. You can have the shell open these file descriptors for your program and have "formal files" as you describe above. To use your example, you could: application <input >logfile 2>errs 3<db1 4<db2 5>rep1 6>rep2 Of course, "application" would have to know which file descriptors to use for which purpose. Also, the first thing that it should do is verify that all of the proper file descriptors are open (fstat(2) would work). There is a limitation, though. In this case you might want to have db1 and db2 open for both reading and writing, but there is no way to make the shell do that do you. You could always have one file descriptor for reading and one for writing on the same file, but that isn't always what you really want to do.... -- Michael J. Spitzer Purdue University Computing Center mjs@mentor.cc.purdue.edu pur-ee!mentor.cc.purdue.edu!mjs
gefuchs@skolem.uucp (Gill E. Fuchs) (05/08/89)
one difficulty with unix (maybe local to the domains i've seen only) is the immediate i/o feedback syndrom: what do i mean? well, suppose one types into the read-a-head buffer some 23 commands. the commands echo immediately, not later in their appropriate location. has anyone found a panacea for that, by the way? thanks gill
bernsten@phoenix.Princeton.EDU (Dan Bernstein) (05/08/89)
VMS lovers say that logical file names aren't available under UNIX. Environment variables are used for particular functions within some range of programs that understand the variable (so that EDITOR is a widely understood variable naming an editing program, and BLTINPUT is a variable understood only by program blt for command input); the standard interfaces for opening a file do not check the environment for filename subtitutions. Symbolic links are better but are stuck within a particular directory and must be explicitly deleted. The obvious UNIX solution is to put these functions in the shell. Shell variables disappear at the end of a session, or you can put them in a standard .-file; everything that VMS users want of a logical file name can be done by appropriate shell features. None of the standard shells have such features (though I remember someone asking why filename ``blackhole'' seemed to act like /dev/null); but it's a perfectly reasonable thing to put into forthcoming shells. Then if someone really wants blackhole to be a non-directory-specific logical file name pointing to /dev/null, it would be easy to set up. Until someone provides a shell with logical file name features, VMS lovers will keep laughing that UNIX can't do the job. After the shell appears, we UNIX lovers will snicker at an operating system so inextensible that adding a new feature requires rewriting the entire system. ---Dan Bernstein, bernsten@phoenix.princeton.edu
jeffrey@algor2.UUCP (Jeffrey Kegler) (05/08/89)
In article <2656@mentor.cc.purdue.edu= mjs@mentor.cc.purdue.edu (Mike Spitzer) writes: =In article <424@algor2.UUCP> jeffrey@algor2.UUCP (Jeffrey Kegler) writes: ==I miss very little from the IBM world, but the availability of formal file ==names is one of them. = =The Bourne shell and other reasonably sh-compatatible shells (like =ksh) allow the redirection of any file descriptor, not just stdin, =stdout, and stderr. You can have the shell open these file =descriptors for your program and have "formal files" as you describe =above. To use your example, you could: = = application <input >logfile 2>errs 3<db1 4<db2 5>rep1 6>rep2 = You probably have not seen the above technique used very often, and for good reason. It requires you to know the order in which the files were opened, which is rather a subtle property to make a shell script depend on. That is why only descriptors 0, 1 and 2 are usually used. The environment opens them for the application, in well known order, and few applications override the environments choices. -- Jeffrey Kegler, President, Algorists, jeffrey@algor2.UU.NET or uunet!algor2!jeffrey 1762 Wainwright DR, Reston VA 22090
jeffrey@algor2.UUCP (Jeffrey Kegler) (05/08/89)
In article <676@dtscp1.UUCP> scott@dtscp1.UUCP (Scott Barman) writes: =In article <424@algor2.UUCP> jeffrey@algor2.UUCP (Jeffrey Kegler) writes: ==I miss very little from the IBM world, but the availability of formal file ==names is one of them. = =Is this anything like trying to remember which utilities wants their =input from ddname SYSUT1 or SYSIN? Or ourput to SYSOUT or SYSPRINT =or even SYSUT2? = =I do not miss anything from that world!!!! It might have been more politic if I had mentioned that most of my experience with formal file names comes from a proprietary (and I assume extinct) HP operating system called MPE. So the idea is not really an IBM one, though most people who have run into it will know it through JCL. It is probably JCL's *only* nice feature. The problem of memorizing a multiplicity of names, is definitely there, but inherent in the problem. Memorizing a lot of option letters, different for each utility, is also hard (though multi-letter options would have been nice). The claim that restricting formal file descriptors to 3 makes them easy to memorize, while true, is a little like the Mac mouse's claim that having only one button made it easy to use. Then along come applications which require double and triple clicking. Really what Scott is saying is that he has never come across an application requiring more than SYSIN, SYSOUT and SYSERR. He probably has. They certainly exist. Databases I mentioned. Sdb really needs a least 2 sets of the 3 formal file names, one for itself and one for the program being debugged. More complex debugging situations than this are easy to imagine. Any of you who have quarreled with another developer over the fact that he was putting out too many debugging messages, really could use a SYSLOG in addition to SYSERR. A transaction oriented environment where enough bucks are at stake will attract auditors who want several logs. A lot of larger applications require you to declare half a dozen environment variables telling you where the files it wants are. And are SYSIN, SYSOUT and SYSERR really harder to remember than 0, 1 and 2? -- Jeffrey Kegler, President, Algorists, jeffrey@algor2.UU.NET or uunet!algor2!jeffrey 1762 Wainwright DR, Reston VA 22090
lawrence@its.rpi.edu (David Lawrence) (05/08/89)
In article <1528@cmx.npac.syr.edu> gefuchs@skolem.uucp (Gill E. Fuchs) writes:
GEF> well, suppose one types into the read-a-head buffer some 23 commands.
GEF> the commands echo immediately, not later in their appropriate location.
GEF> has anyone found a panacea for that, by the way?
Yes, three shells which I know of all do what you desire (or close to
it; read on). Shells which emulate an Emacs- or vi-like interface to
the system read their input character at a time. When a character is
typed that is meant to be visible, it writes it to the display. So
while your command is being execed by the shell, your type-ahead stdin
is buffered for the shell. When the shell gets to its stdin reading
loop (after the exec and any miscellaneous shell activities), it
gets all of those characters you typed and proceeds to interpret/
display them as required. The net effect of this is to have your
typed-ahead command displayed where it belongs after your prompt (with
occasional characters before the prompt depending on unfortunate
timing).
The reason I said "close to" up there is because a limitation of at
least one of these shells, tcsh, is that you cannot type more than one
command ahead because anything after the first is ignored. Rather
annoying sometimes, but I like the shell enough otherwise that I can
overlook the shortcoming (but if you want to fix it, Paul, I know a
few people who wouldn't mind. :-).
The other two shells, by the way, are ksh and ecsh.
Dave
--
tale@rpitsmts.bitnet, tale%mts@itsgw.rpi.edu, tale@pawl.rpi.eduscott@dtscp1.UUCP (Scott Barman) (05/08/89)
In article <429@algor2.UUCP> jeffrey@algor2.UUCP (Jeffrey Kegler) writes: >In article <676@dtscp1.UUCP> scott@dtscp1.UUCP (Scott Barman) writes: >=In article <424@algor2.UUCP> jeffrey@algor2.UUCP (Jeffrey Kegler) writes: >==I miss very little from the IBM world, but the availability of formal file >==names is one of them. >= >=Is this anything like trying to remember which utilities wants their >=input from ddname SYSUT1 or SYSIN? Or ourput to SYSOUT or SYSPRINT >=or even SYSUT2? >= >=I do not miss anything from that world!!!! > >The problem of memorizing a multiplicity of names, is definitely there, but >inherent in the problem. Memorizing a lot of option letters, different for >each utility, is also hard (though multi-letter options would have been nice). > [...] >Really what Scott is saying is that he has never come across an application >requiring more than SYSIN, SYSOUT and SYSERR. He probably has. They >certainly exist. No, what Scott is saying is there is at least a consistancy! The standard input is alway the standard input and it is found at fd 0, the standard output is always the standard output and is found at fd 1, the standard error output is always the standard error output and is found at fd 3. If nothing else has, this has been consistant--at least since version 6! The problem I mentioned with the multiple names (above) are not consistant and got very annoying and led me to have to learn to write clists (I learned this under TSO) or I would never remember which used what. > Any of you who >have quarreled with another developer over the fact that he was putting out >too many debugging messages, really could use a SYSLOG in addition to >SYSERR. Redirect standard error--and atleast you can find it and not guess which ddname it is using! > A transaction oriented environment where enough bucks are at stake >will attract auditors who want several logs. A lot of larger applications >require you to declare half a dozen environment variables telling you where >the files it wants are. That is the deficiency of the program, not the environment it is running on. I have found many times that these large "canned" applications have been written by Unix "converts" who came over from the mainframe world and do not (or have yet--at the time) the knowledge necessary to mold the ideas properly into the environment. Software I have seen from Unix developers for Unix systems seems to have been well thought out as to their interaction with the environment. So don't judge the system when it is the fault of the brain damaged applications! >And are SYSIN, SYSOUT and SYSERR really harder to remember than 0, 1 and 2? If they remained that consistant, the only problem I have is with the names. They are not consistant with the Unix environment and I prefer to stick with this long-time convention! -- scott barman {gatech, emory}!dtscp1!scott
daveh@marob.MASA.COM (Dave Hammond) (05/09/89)
In article <19472@adm.BRL.MIL> Kemp@DOCKMASTER.NCSC.MIL writes: >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 > as well as writing application programs that use them. Environment >variables won't work unless you rewrite all your applications AND ALL >UNIX APPLICATIONS to do a getenv before every open (figure the odds!). That's silly. If you substitute environ vars for `joe' and `splib' in the previous example, ie: cd $joe ls $joe ar t $splib cc myprog -l$splib it is the shell which must expand `$joe' and `$splib', not your application. Rest assured, the shell will do so. -- Dave Hammond daveh@marob.masa.com
friedl@vsi.COM (Stephen J. Friedl) (05/09/89)
In article <2656@mentor.cc.purdue.edu>, mjs@mentor.cc.purdue.edu (Mike Spitzer) writes: > application <input >logfile 2>errs 3<db1 4<db2 5>rep1 6>rep2 > [...] > > There is a limitation, though. In this case you might want to have > db1 and db2 open for both reading and writing, but there is no way to > make the shell do that do you. The Bourne shell (but not ksh) allows application <> dbfile where "dbfile" is open for read and write. One probably shouldn't rely on this, but it's fun to think about... Steve -- Stephen J. Friedl / V-Systems, Inc. / Santa Ana, CA / +1 714 545 6442 3B2-kind-of-guy / friedl@vsi.com / {attmail, uunet, etc}!vsi!friedl "California: the land of cute women, hot tubs, and no rust" - me
gandalf@csli.Stanford.EDU (Juergen Wagner) (05/10/89)
In article <1528@cmx.npac.syr.edu> gefuchs@logiclab.cis.syr.edu (Gill E. Fuchs) writes: >one difficulty with unix (maybe local to the domains i've seen only) >is the immediate i/o feedback syndrom: > >what do i mean? > >well, suppose one types into the read-a-head buffer some 23 commands. >the commands echo immediately, not later in their appropriate location. Umm... How do you know the third command doesn't fail? What if it fails? What if you have a typo in the second command? >has anyone found a panacea for that, by the way? Don't do it! Typing ahead some 23 commands is not necessary. If you want to execute a sequence of 23 command, put them on a line, separated by ';', or even better, put them into a file (since you might want to reuse this sequence later). -- Juergen Wagner gandalf@csli.stanford.edu wagner@arisia.xerox.com
usenet@cps3xx.UUCP (Usenet file owner) (05/10/89)
In article <8892@csli.Stanford.EDU> gandalf@csli.stanford.edu (Juergen Wagner) writes: >In article <1528@cmx.npac.syr.edu> gefuchs@logiclab.cis.syr.edu (Gill E. Fuchs) writes: >>one difficulty with unix (maybe local to the domains i've seen only) >>is the immediate i/o feedback syndrom: >> >>what do i mean? >> >>well, suppose one types into the read-a-head buffer some 23 commands. >>the commands echo immediately, not later in their appropriate location. > >Umm... How do you know the third command doesn't fail? What if it fails? >What if you have a typo in the second command? I watch the output, and hit control-X to cancel the third command if the second command fails. >Don't do it! Typing ahead some 23 commands is not necessary. If you want to >execute a sequence of 23 command, put them on a line, separated by ';', or >even better, put them into a file (since you might want to reuse this sequence >later). I know it isn't necessary. I can type in a command, press return, wait for it to finish, type another command, press return, wait for it to finish, .... But it's much faster to use typeahead. Having it echo in the middle of my output is quite annoying, though. (Then again, I worked with Apple ][, IBM-PC, and VMS systems--which have typeahead working "right"--before I worked with UNIX; maybe one gets used to this weirdness eventually.) Does anyone know the original reason for the immediate echoing? +---------------------------+------------------------+-------------------+ | 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". | +---------------------------+------------------------+-------------------+
gandalf@csli.Stanford.EDU (Juergen Wagner) (05/10/89)
In article <2914@cps3xx.UUCP> rang@cpsin3.cps.msu.edu (Anton Rang) writes: >... > Does anyone know the original reason for the immediate echoing? >... The question which has to be raised is who echoes the characters as they are typed. Is it the driver which is in some echo mode, or is it the application (shell, emacs, whatever)? Sh/csh don't know about echoing. They happily process characters as they come along. (Famous example: killing certain programs leaves the terminal in a bad, non-echoing state) The alternative would be to require the application to echo characters just as it reads them (this would give you the desired behaviour). However, what happens if you invoke a program from csh? Should the program be expected to handle all echoing, or should the driver now take over? I guess, somebody has made a decision towards simplicity, and has chosen to let the driver echo input unless the application explicitly resets the terminal mode. -- Juergen Wagner gandalf@csli.stanford.edu wagner@arisia.xerox.com
usenet@cps3xx.UUCP (Usenet file owner) (05/11/89)
In article <8907@csli.Stanford.EDU> gandalf@csli.stanford.edu (Juergen Wagner) writes: >In article <2914@cps3xx.UUCP> rang@cpsin3.cps.msu.edu (Anton Rang) writes: >>... >> Does anyone know the original reason for the immediate echoing? >>... > >The question which has to be raised is who echoes the characters as they >are typed. Is it the driver which is in some echo mode, or is it the >application (shell, emacs, whatever)? > > [...] > >The alternative would be to require the application to echo characters just >as it reads them (this would give you the desired behaviour). Umm, to display my ignorance of UNIX device driver internals, why can't it be done like this? 1. User types character. Driver puts it in some queue. 2. Application wants character. Calls [ something ] to get it from queue. [ something ] echoes it. After all, applications don't directly grab characters; if they're going through some common point, you could do echoing there. (Right?) +---------------------------+------------------------+-------------------+ | 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". | +---------------------------+------------------------+-------------------+
jeffrey@algor2.UUCP (Jeffrey Kegler) (05/11/89)
In article <2656@mentor.cc.purdue.edu>, mjs@mentor.cc.purdue.edu (Mike Spitzer) writes: > application <input >logfile 2>errs 3<db1 4<db2 5>rep1 6>rep2 > [...] > In a previous followup to this message I asserted that this syntax is highly dependent on the order of open() calls in the application. That turns out to wrong as a few people have pointed out to me by Email. The rules, as I now understand them, are 1) The shell opens file descriptors 0, 1 and 2. 2) It also opens any descriptors explicitly redirected on the command line (3 through 6, in the above). 3) It also opens any descriptors explicitly redirected in exec commands. 4) The application's open() calls return the remaining file descriptors, lowest first. This actually forms a fairly reasonable replacement to logical file names. Remaining problem: Any file descriptors whose redirection is forgotten, are returned in response to the application's open calls. This could cause wierd open() order dependent behavior. The logging data could wind up being written into the database, for example. -- Jeffrey Kegler, President, Algorists, jeffrey@algor2.UU.NET or uunet!algor2!jeffrey 1762 Wainwright DR, Reston VA 22090
woods@eci386.uucp (Greg Woods) (05/13/89)
In article <2914@cps3xx.UUCP> rang@cpsin3.cps.msu.edu (Anton Rang) writes: > .... But it's much faster to use typeahead. Having it > echo in the middle of my output is quite annoying, though. (Then > again, I worked with Apple ][, IBM-PC, and VMS systems--which have > typeahead working "right"--before I worked with UNIX; maybe one gets > used to this weirdness eventually.) > Does anyone know the original reason for the immediate echoing? So that you can see what you've typed, and there by correct any mistakes you might have made. Of course any good shell will be re-echoing what you've typed on the prompt line (ala ksh, tcsh, and some csh's) at time of execution. Primarily you'll only be using typeahead if you have entered a command which takes a considerable amount of time, and you do not want to, or cannot interrupt it and re-start it in the background. And when spurious output from this command interrupts your typing, perhaps causing you to make a mistake, you become acutely aware of the reasoning behind the invention of the BSD newtty line discipline, and its re-type feature. -- Greg A. Woods woods@{{utgpu,eci386,ontmoh,tmsoft}.UUCP,gpu.utcs.UToronto.CA,utorgpu.BITNET} +1-416-443-1734 [h] +1-416-595-5425 [w] Toronto, Ontario CANADA
stacy@mcl.UUCP (Stacy L. Millions) (05/14/89)
In article <2930@cps3xx.UUCP>, usenet@cps3xx.UUCP (Usenet file owner) writes: > After all, applications don't directly grab characters; if they're > going through some common point, you could do echoing there. (Right?) You want read(2) to write? :-) > | Anton Rang (grad student) | "VMS Forever!" ^^^^^^^^^^^^ At least we know your article is an unbiased oppinion. -stacy -- "Fuzzy Wuzzy was a women?" - Gene Wilder _See No Evil Hear No Evil_ S. L. Millions Millions Computing Ltd. tmsoft!mcl!stacy
dhesi@bsu-cs.bsu.edu (Rahul Dhesi) (05/15/89)
In article <134@mcl.UUCP> stacy@mcl.UUCP (Stacy L. Millions), responding to a "VMS Forever!" person, writes: >You want read(2) to write? :-) It makes a certain amount of vicious sense. In VMS, the only way to write a string from a script without a trailing newline is to use READ rather than WRITE. Honest! -- Rahul Dhesi <dhesi@bsu-cs.bsu.edu> UUCP: ...!{iuvax,pur-ee}!bsu-cs!dhesi
mcdonald@uxe.cso.uiuc.edu (05/15/89)
>I miss very little from the IBM world, but the availability of formal file >names is one of them. Once UNIX starts getting into commercial >environments they will become more useful. I miss NOTHING from the IBM (mainframe) world, and the loss of formal file names is one of the biggest gains! Doug McDonald
duncan@dg-rtp.dg.com (W. Lee Duncan) (05/15/89)
Personally, I like my typeahead to echo. The reason? If I type something
in incorrectly (which, amazingly, happens quite a bit), I can figure it
out just by watching the screen.
Also, one person mentioned that they didn't like how typeahead worked
because when the commands they'd typed ahead finally did get executed,
they didn't see the command echoed then. I think the best solution
to this is how the Korne shell works. When it executes a command,
it looks to see if the command was typed ahead. If so, it echoes
the command itself.
Another person mentioned that they sometimes had to hit "backspace"
just to see which characters disappeared, and which didn't. Most
systems have a "redraw" character (usually "control-R"), so that,
by hitting this character, the current line will be redrawn. You
may not have this though, because, on those systems, if you get
a prompt and you have half of a line typed in, then hit backspace,
the line will redraw itself (as if you had typed the redraw
character). For my info, which systems don't have this.
--
W. Lee Duncan, Data General, RTP - "How can you be two places at once
UUCP: {world}!mcnc!rti!dg-rtp!duncan - when you're really no place at all"
DOMAIN: duncan@dg-rtp.dg.com - Firesign Theatre