pjh@mccc.UUCP (Pete Holsberg) (07/18/89)
If I assign a shell variable a value that contains an asterisk, the
shell behaves strangely if there is a space adjacent to said asterisk.
For example,
x='*z'
echo ${x}
produces
*z
but
x='* z'
echo ${x}
produces
(a list of all the files in the current directory) z
What does the space have to do with this?
Please mail and I'll summarize if there is interest. Thanks.
--
Pete Holsberg -- Mercer College -- Trenton, NJ 08690
...!rutgers!njin!princeton!njsmu!mccc!pjhIA80001@MAINE.BITNET (George Newell) (07/20/89)
When you put the asterisk (*) on a line with spaces around it, the shell will substitute all the names in the current directory for it. Apparently, when you included the letter after the asterisk and space, the shell interpreted the letter as a path name for the directory listing to print. I hope this info helps. George Newell IA80001@MAINE.BITNET
uri@arnor.UUCP (Uri Blumenthal) (07/21/89)
From article <1643IA80001@MAINE>, by IA80001@MAINE.BITNET (George Newell): > When you put the asterisk (*) on a line with spaces around it, the shell will > substitute all the names in the current directory for it. Apparently, when you > included the letter after the asterisk and space, the shell interpreted the > letter as a path name for the directory listing to print. I hope this info > helps. > > Disagree. Shell tries to substitute _special_ symbols. Means - when it sees "normal" letter - it will echo it, simply. So the output of echo * x will be: <current directory list> x That's it. ----------------------- <Standard Disclaimer>
fawcett@steven.COM (fawcett) (07/22/89)
>If I assign a shell variable a value that contains an asterisk, the >shell behaves strangely if there is a space adjacent to said asterisk. >For example, > x='*z' > echo ${x} >produces > *z >but > x='* z' > echo ${x} >produces > (a list of all the files in the current directory) z > >What does the space have to do with this? >Please mail and I'll summarize if there is interest. Thanks. >-- >Pete Holsberg -- Mercer College -- Trenton, NJ 08690 >...!rutgers!njin!princeton!njsmu!mccc!pjh The problem here is that the "set" of x stripped off the single quotes. This left only the *, which matches all occourances of one or more characters. Why it looked in your directory for these files I don't know. The fact that the *z echoed simply means that you don't have any files in your directory that end in the letter z. Try doing a ls *. This will list every file in your directory and every file in any subdirectory you have. The ls will only go down one level, since a ls <dir> will only go down one level. If you wanted to echo the string *, either say echo '*', or try saying set x='* a' echo "${x}" this will echo "* a" (without the quotes, of course). Simularly, saying set x='*' echo "${x}" will echo a "*" (without the quotes, of course). Hope this helps. John W. Fawcett ----- ----- ----- ----- ----- ------ Software Engineer / / / / / / / / / Sierra Geophysics, Inc . ----- / /--- /----- /----- /-----/ P.O. Box 3886 / / / / \ / \ / / Seattle, Wa. 98124 ----- ----- ----- / \ / \ / / Voice: (206) 822-5200 uucp: ..!uw-beaver!sumax!quick!ole!steven!fawcett
funk@osiris.cso.uiuc.edu (07/22/89)
fawcett@steven.com writes: >pjh@mcc.UUCP writes: >>If I assign a shell variable a value that contains an asterisk, the >>shell behaves strangely if there is a space adjacent to said asterisk. >>For example, >> x='*z' >> echo ${x} >>produces >> *z >>but >> x='* z' >> echo ${x} >>produces >> (a list of all the files in the current directory) z >> >>What does the space have to do with this? >The problem here is that the "set" of x stripped off the single quotes. >This left only the *, which matches all occourances of one or more >characters. Why it looked in your directory for these files I don't know. >The fact that the *z echoed simply means that you don't have any files in >your directory that end in the letter z. > Ummm... I had always learned (obviously flawed) that the single quotes prevented expansion of ANYTHING.... Even if this is not the case, why does it behave differently in the two cases? If you have no files ending in z , then why does it not return a null string for the '*z' version ? What is its algoithm for determining when it is going to be literal and when it is going to expand??? ------------------------------------------------------------------------------- | Bruce Funk INTERNET: funk@osiris.cso.uiuc.edu | |ACSEH, 21st TAACOM __________________________________________________| |Kaiserslautern, W. Germany | Any resemblance between me and reality | |(guesting on osiris) | is strictly coincidental | -------------------------------------------------------------------------------
tale@pawl.rpi.edu (David C Lawrence) (07/23/89)
In <9700009@osiris.cso.uiuc.edu> funk@osiris.cso.uiuc.edu writes:
funk> Ummm... I had always learned (obviously flawed) that the single
funk> quotes prevented expansion of ANYTHING.... Even if this is not
funk> the case, why does it behave differently in the two cases? If
funk> you have no files ending in z , then why does it not return a
funk> null string for the '*z' version ? What is its algoithm for
funk> determining when it is going to be literal and when it is going
funk> to expand???
The example in question is comparison of the following.
$ x='*z' ; echo $x
vs
$ x='* z' ; echo $x
The original poster request that he be responded to in mail. Since
the person who Mr Funk is responding to decided that he would post his
wonderful (!) explanation to the net instead, we have the potential to
see this discussed for much too long. Hopefully this will prevent
that.
The Bourne shell is _not_ the C shell. Globbing (filename expansion)
is done differently. If the shell (sh, not csh) cannot find an
expansion for the wildcards, it just leaves it. Single quotes and
double quotes both prevent globbing.
Here are some more examples to clear it up a little:
$ x=* # x is set to a list of non-dotfiles in the current directory.
$ x='*' # x is set to just *
$ x="*" # x is still set to just *
In the example that started all of this, x was set to the string which
was typed. After variable substitution was done but before the
arguments were passed to echo, the shell did globbing on what the line
then looked like -- namely "echo *z" or "echo * z". Since it couldn't
find filenames ending in z, it just passed *z as the argument. In the
second case it expanded * to all the files in the directory and passed
them and z as arguments to echo.
Dave
--
(setq mail '("tale@pawl.rpi.edu" "tale@itsgw.rpi.edu" "tale@rpitsmts.bitnet"))chris@mimsy.UUCP (Chris Torek) (07/24/89)
Pete Holsberg was going to summarise replies, but I have seen so many partial and/or wrong answers on the net already that I feel I should post this. [Bourne shell] >> x='*z' >> echo ${x} >>produces >> *z >>but >> x='* z' >> echo ${x} >>produces >> (a list of all the files in the current directory) z In article <53@steven.COM> fawcett@steven.COM (fawcett) writes: >The problem here is that the "set" of x stripped off the single quotes. >This left only the *, which matches all occourances of one or more >characters. Why it looked in your directory for these files I don't know. (One is tempted to ask, `if you do not know, why do you post?' :-) ) But this answer is partly right, and the suggested fix (deleted) is correct. >The fact that the *z echoed simply means that you don't have any files in >your directory that end in the letter z. Just so. The complete answer to the original question can be found in the manual for sh(1). (Surprise!) Perhaps we should have a look: Parameter substitution. The character $ is used to introduce substitutable parame- ters. ... Variables may be set by writing name=value [ name=value ] ... ${parameter} A parameter is a sequence of letters, digits or under- scores (a name), a digit, or any of the characters * @ # ? - $ !. The value, if any, of the parameter is sub- stituted. The braces are required only when parameter is followed by a letter, digit, or underscore that is not to be interpreted as part of its name. ... Blank interpretation. After parameter and command substitution, any results of substitution are scanned for internal field separator char- acters (those found in $IFS) and split into distinct argu- ments where such characters are found. Explicit null argu- ments ("" or '') are retained. Implicit null arguments (those resulting from parameters that have no values) are removed. File name generation. Following substitution, each command word is scanned for the characters *, ? and [. If one of these characters appears, the word is regarded as a pattern. The word is replaced with alphabetically sorted file names that match the pat- tern. If no file name is found that matches the pattern, the word is left unchanged. The character . at the start of a file name or immediately following a /, and the character /, must be matched explicitly. Now, note in particular the order of evaluation: parameter substitution is done first (`${x}' is expanded), then blanks are interpreted (`z *' becomes two distinct arguments while `z*' becomes one distinct argument), then file names are generated (`*' becomes `all files except those that start with `.'; `z*' becomes `all files that start with z'; if neither expands at all, it remains as it was). We need to read a bit further for solutions: Quoting. The following characters have a special meaning to the shell and cause termination of a word unless quoted. ; & ( ) | < > newline space tab A character may be quoted by preceding it with a \. \new- line is ignored. All characters enclosed between a pair of quote marks (''), except a single quote, are quoted. Inside double quotes ("") parameter and command substitution occurs and \ quotes the characters \ ' " and $. "$*" is equivalent to "$1 $2 ..." whereas "$@" is equivalent to "$1" "$2" ... . This means that we cannot use '$x' (since single quotes prevent variable substitution), but we can use "$x" (since double quotes do not). This does, however, have the side effect of making the expansion of $x a single `word' (since the expansion is surrounded by double quotes, which quote space, tab, and newline, the default IFS characters). Quoting filename and/or shell metacharacters without quoting IFS characters can be a bit of a challenge. The solution to that remains as an exercise for the student, as it were. (Quoting IFS characters is easy: simply change IFS.) -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
dce@Solbourne.COM (David Elliott) (07/24/89)
In article <9700009@osiris.cso.uiuc.edu> funk@osiris.cso.uiuc.edu writes: >>pjh@mcc.UUCP writes: >>> x='*z' >>> echo ${x} >>>produces >>> *z >>>but >>> x='* z' >>> echo ${x} >>>produces >>> (a list of all the files in the current directory) z > Ummm... I had always learned (obviously flawed) that the single quotes >prevented expansion of ANYTHING.... >Even if this is not the case, why does it behave differently in the two cases? >If you have no files ending in z , then why does it not return a null >string for the '*z' version ? What is its algoithm for determining when it is going to be literal and when it is going to expand??? Don't confuse yourself. The assignment x='anything' assigns the word to x *without* the single quotes. The single quotes do prevent all expansion, just as if each character were preceded by a \ (the exception is in csh, in which a single-quoted ! must still be escaped to prevent history expansion). When you execute echo ${x} the shell expands the value of the variable x, doing all processing that occurs after variable substitution, which includes filename expansion. If the statement were instead (and I wish people would learn to use this, since it's the correct thing to do) echo "${x}" the shell would expand the variable, but leave its contents alone, because of the double quotes. Now, as to why echo * z expands the * and echo *z doesn't, it's simply because sh is defined that way. If it can't expand the name, it leaves it alone. You can do the same thing in csh by setting "nonomatch" (and you thought this was an admonishment to a naughty child ;-). -- David Elliott dce@Solbourne.COM ...!{boulder,nbires,sun}!stan!dce
guy@auspex.auspex.com (Guy Harris) (07/25/89)
> Ummm... I had always learned (obviously flawed) that the single quotes >prevented expansion of ANYTHING.... They do. That's why the statement x='*z' assigns the string "*z" to the variable "x". Note, though, that the string is "*z", not "'*z'" - in other words, the quotes are gone. (The quotes in "*z" in the statment ...assigns the string "*z" to the variable "x". mark the boundaries of the string; they are *not* part of the string. In other words, the variable "x" has a two-character string as its value, the first character of which is '*' and the second character of which is 'z'.) This means that the statement echo ${x} is expanded to echo *z by substituting the value of the variable "x" for the "${x}". *After* the substitution is performed, the command is cut up into tokens; the two tokens in this case are "echo" and "*z". Then the tokens have file-name expansion performed on them, so that "*z" expands either to a list of all the files whose names end with "z", if there are any such files, or to a list containing only "*z", if there aren't any such files. (All this is covered in the SH(1) man page in SunOS, and I think that's pretty much derived from the S5 man page, so it should be there as well. It takes a bit of searching to find the pieces of the description.) >Even if this is not the case, why does it behave differently in the two >cases? Because the "tokenization" is done between the variable expansion and the file name expansion. Thus, x='* z' assigns the three-character string "* z" to the variable "x", just as x='*z' assigned the two-character string "*z" to "x". The statement echo ${x} is then expanded into echo * z when the value of "x" is substituted into it. The quotes are not preserved, remember, so this is then broken into *three* tokens - "echo", "*", and "z". The first and third tokens expand to themselves when file-name expansion is performed; the second token expands to a list of all files in the current directory (except for those whose name begins with "."). Now if you want the "echo" to literally echo the value of "x", you should do echo "${x}" # or just echo "$x" because double-quotes prevent file-name expansion but do *not* prevent variable-name expansion. If you want "echo" to echo the string "${x}", rather than the value of the variable "x", do echo '${x}' >If you have no files ending in z , then why does it not return a null >string for the '*z' version ? Because that's the way the Bourne shell works. If a filename pattern doesn't match any file names, it is left unchanged, not expanded to a null string or a null list.
nichiren@glyph.UUCP (Andy Heffernan) (07/26/89)
In article <2277@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes: >> Ummm... I had always learned (obviously flawed) that the single quotes >>prevented expansion of ANYTHING.... > [much deleted] > >>If you have no files ending in z , then why does it not return a null >>string for the '*z' version ? > >Because that's the way the Bourne shell works. If a filename pattern >doesn't match any file names, it is left unchanged, not expanded to a >null string or a null list. Yes, indeed. For a simple-minded example of this feature in action, we Bourne/Korn shell users can get away with: $ uucp whereever!~uucp/goodstuff/* ~uucp/cache to get everything in whereever's public goodstuff directory. Unless your current directory contains a directory named "whereever!~uucp" which contains a directory named "goodstuff", which in turn has some non-dot files in it, the first argument to the command will expand to itself, and so get passed to 'whereever' for expansion. For C-shell users, at least the * in the above command needs quoting against interpretation, and I guess the ! as well. (Beats me, I just ^P.) -- ------------------------------------------------------------------------- Andy Heffernan uunet!glyph!nichiren [1222 - 1282] ------------------------------------------------------------------------- "Dogpile on the rabbit! Dogpile on the rabbit!"
peter@ficc.uu.net (Peter da Silva) (07/27/89)
In article <470@glyph.UUCP>, nichiren@glyph.UUCP (Andy Heffernan) writes: > For C-shell users, at least the * in the above command needs quoting > against interpretation, and I guess the ! as well. (Beats me, I just ^P.) % set nonomatch # Don't complain about unmatched stuff % set histchars='%^' # And forget about ! in paths. % uucp somewhere!~/get/* ~/get % %%:s/get/put/g uucp somewhere!~/put/* ~/put % [] I've used ksh history at 300 baud. I'll stick with csh. The right place for ksh -type command line editing is in the terminal driver or xterm! -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Business: peter@ficc.uu.net, +1 713 274 5180. | "...helping make the world Personal: peter@sugar.hackercorp.com. `-_-' | a quote-free zone..." Quote: Have you hugged your wolf today? 'U` | -- hjm@cernvax.cern.ch
pjh@mccc.UUCP (Pete Holsberg) (07/27/89)
In article <TALE.89Jul22220358@imagine.pawl.rpi.edu> tale@pawl.rpi.edu writes:
=Here are some more examples to clear it up a little:
=$ x=* # x is set to a list of non-dotfiles in the current directory.
=$ x='*' # x is set to just *
=$ x="*" # x is still set to just *
Dave has hit it on the nose. An assignment such as x="*" does NOT
assign "*" to z; it assigns * to x. When the value of x is retrieved,
the shell sees the metacharacter * and expands it to all non-hidden
filenames in the current directory.
Thanks to Dave and the kind folks who responded by email.
--
Pete Holsberg -- Mercer College -- Trenton, NJ 08690
...!rutgers!njin!princeton!njsmu!mccc!pjhtale@pawl.rpi.edu (David C Lawrence) (07/28/89)
In article <TALE.89Jul22220358@imagine.pawl.rpi.edu> I apparently wrote: Me> Here are some more examples to clear it up a little: Me> $ x=* # x is set to a list of non-dotfiles in the current directory. Me> $ x='*' # x is set to just * Me> $ x="*" # x is still set to just * In <446@mccc.UUCP> pjh@mccc.UUCP (Pete Holsberg) writes: PH> Dave has hit it on the nose. Whonk. Dave should be hit _in_ the nose. I'm surprised I let that come out. The first example is bogus. Globbing is not done on the RHS of variable assignment. That is, it isn't done on the value to be assigned. If it had been $ x= * Then, assuming you had at least one file in the directory, an attempt would be made to execute the first one to which * expanded with the rest as arguments. Fun, ne? Sorry about the error, Dave -- (setq mail '("tale@pawl.rpi.edu" "tale@itsgw.rpi.edu" "tale@rpitsmts.bitnet"))
pjh@mccc.UUCP (Pete Holsberg) (07/30/89)
In article <TALE.89Jul27194738@imagine.pawl.rpi.edu> tale@pawl.rpi.edu writes: =In article <TALE.89Jul22220358@imagine.pawl.rpi.edu> I apparently wrote: =Me> Here are some more examples to clear it up a little: =Me> $ x=* # x is set to a list of non-dotfiles in the current directory. =Me> $ x='*' # x is set to just * =Me> $ x="*" # x is still set to just * = =In <446@mccc.UUCP> pjh@mccc.UUCP (Pete Holsberg) writes: =PH> Dave has hit it on the nose. = =Whonk. Dave should be hit _in_ the nose. Consider it done! =I'm surprised I let that =come out. The first example is bogus. Globbing is not done on the =RHS of variable assignment. Why not? =If it had been = =$ x= * = =Then, assuming you had at least one file in the directory, an attempt =would be made to execute the first one to which * expanded with the =rest as arguments. How about a logical explanation of why x=* x="*" and x='*' have the same effect?? -- Pete Holsberg -- Mercer College -- Trenton, NJ 08690 ...!rutgers!princeton!njsmu!mccc!pjh
dave@micropen (David F. Carlson) (07/31/89)
In article <5275@ficc.uu.net>, peter@ficc.uu.net (Peter da Silva) writes: > > The right place for ksh -type command line editing is in the terminal > driver or xterm! > -- > Peter da Silva, Xenix Support, Ferranti International Controls Corporation. The *wrong* place for command line editing is in the terminal driver. Kernel is for what is difficult or impossible to do in user space. Keep it clean and small. -- David F. Carlson, Micropen, Inc. micropen!dave@ee.rochester.edu "The faster I go, the behinder I get." --Lewis Carroll
gwyn@smoke.BRL.MIL (Doug Gwyn) (08/01/89)
In article <815@micropen> dave@micropen (David F. Carlson) writes: -In article <5275@ficc.uu.net>, peter@ficc.uu.net (Peter da Silva) writes: -> The right place for ksh -type command line editing is in the terminal -> driver or xterm! -The *wrong* place for command line editing is in the terminal driver. Some of us think the right place is in the terminal!
peter@ficc.uu.net (Peter da Silva) (08/01/89)
In article <815@micropen>, dave@micropen (David F. Carlson) writes: > In article <5275@ficc.uu.net>, peter@ficc.uu.net (Peter da Silva) writes: > > The right place for ksh -type command line editing is in the terminal > > driver or xterm! > The *wrong* place for command line editing is in the terminal driver. > Kernel is for what is difficult or impossible to do in user space. Keep it > clean and small. Who said anything about the kernel? I said "in the terminal driver or xterm". There's no real reason for the terminal driver to live entirely in kernel space, other than historical. -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Business: peter@ficc.uu.net, +1 713 274 5180. | "The sentence I am now Personal: peter@sugar.hackercorp.com. `-_-' | writing is the sentence Quote: Have you hugged your wolf today? 'U` | you are now reading"
peter@ficc.uu.net (Peter da Silva) (08/01/89)
In article <10639@smoke.BRL.MIL>, gwyn@smoke.BRL.MIL (Doug Gwyn) writes: > -In article <5275@ficc.uu.net>, peter@ficc.uu.net (Peter da Silva) writes: > -> The right place for ksh -type command line editing is in the terminal > -> driver or xterm! > Some of us think the right place is in the terminal! That's the moral equivalent of the terminal driver. My Amiga gives me this sort of capability, via cut and paste with the mouse, as do other people's Macs and Atari STs if they have any sort of decent terminal program (when I had an ST, I didn't, but that was a long time ago and I don't hold that agin it). The one problem with this approach is that you really should only maintain a command line history when you're in canonical mode (ICANON, or COOKED). You don't want your vi or emacs commands messing up your buffer. I guess you could modify the termcap for your terminal to turn buffering off and on when you enter or leave a screen-oriented program... (goes off muttering about VS and VE...) -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Business: peter@ficc.uu.net, +1 713 274 5180. | "The sentence I am now Personal: peter@sugar.hackercorp.com. `-_-' | writing is the sentence Quote: Have you hugged your wolf today? 'U` | you are now reading"
debra@alice.UUCP (Paul De Bra) (08/03/89)
In article <5404@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: }In article <10639@smoke.BRL.MIL>, gwyn@smoke.BRL.MIL (Doug Gwyn) writes: }> -> The right place for ksh -type command line editing is in the terminal }> -> driver or xterm! } }> Some of us think the right place is in the terminal! } }That's the moral equivalent of the terminal driver. My Amiga gives me this }sort of capability, via cut and paste with the mouse, as do other people's }Macs and Atari STs if they have any sort of decent terminal program (when }I had an ST, I didn't, but that was a long time ago and I don't hold that }agin it). } }The one problem with this approach is that you really should only maintain }a command line history when you're in canonical mode (ICANON, or COOKED). }You don't want your vi or emacs commands messing up your buffer. I guess }you could modify the termcap for your terminal to turn buffering off and }on when you enter or leave a screen-oriented program... (goes off muttering }about VS and VE...) Yep, you just reinvented the jerq, blit, 5620 (or whatever generation) terminal. Multiple windows, a special protocol for communication with the multiple processes on the host, local command line editing in the terminal (cut, paste, mouse driven)... Special terminal ioctl's to turn echo on and off (you wouldn't want half-duplex while typing a password), etc. We could hardly believe our eyes when we discovered that this local command line editing went away in the new and "improved" AT&T 630 MTG terminal. (sigh) Paul. -- ------------------------------------------------------ |debra@research.att.com | uunet!research!debra | ------------------------------------------------------
gwyn@smoke.BRL.MIL (Doug Gwyn) (08/03/89)
In article <5404@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: -In article <10639@smoke.BRL.MIL>, gwyn@smoke.BRL.MIL (Doug Gwyn) writes: -> Some of us think the right place is in the terminal! -The one problem with this approach is that you really should only maintain -a command line history when you're in canonical mode (ICANON, or COOKED). -You don't want your vi or emacs commands messing up your buffer. ... The terminal shouldn't know what a "command line" is. Therefore it shouldn't be making this distinction. I snarf&barf text freely between editor displays, command lines, and other text sources/sinks all the time.
richard@aiai.ed.ac.uk (Richard Tobin) (08/04/89)
]-] Some of us think the right place is in the terminal! ]-The one problem with this approach is that you really should only maintain ]-a command line history when you're in canonical mode (ICANON, or COOKED). ]The terminal shouldn't know what a "command line" is. Therefore it ]shouldn't be making this distinction. I snarf&barf text freely between ]editor displays, command lines, and other text sources/sinks all the time. Sure, but there's more to command-line editing than "snarf&barf". If you want to always be able to get your previous shell command by typing control-P, and would like that to work in Lisp and /bin/cat as well, but you also want control-P to be passed direct to emacs, then it's fairly difficult for a terminal on a serial line to keep track. It should be possible (if you have ptys) to write a program that provides you with line-based command editing only when the terminal is in cooked mode. (It would be rather like "script".) At present that requires checking the terminal mode for each character typed - it would be nice if there were a pty mode that told you when ioctls are done on the slave side. -- Richard -- Richard Tobin, JANET: R.Tobin@uk.ac.ed AI Applications Institute, ARPA: R.Tobin%uk.ac.ed@nsfnet-relay.ac.uk Edinburgh University. UUCP: ...!ukc!ed.ac.uk!R.Tobin
gwyn@smoke.BRL.MIL (Doug Gwyn) (08/04/89)
In article <9729@alice.UUCP> debra@alice.UUCP () writes: >We could hardly believe our eyes when we discovered that this local command >line editing went away in the new and "improved" AT&T 630 MTG terminal. (sigh) Well you shouldn't believe your eyes! The 630 firmware, unlike the 5620 which was comparatively "plain", supports mouse-driven cut, paste, and send. I use it continually. It's not quite like Rob's "mux" interface, alas, but the capability's there. Maybe you got one of the pre-release versions of the firmware. 5620 users who are using the commercial version of "layers" can obtain "mux"-like editing features, scrolling, etc. by obtaining Dave Prosser's "myx" terminal emulator (part of the AT&T UNIX System ToolChest "dmd-pgmg" package). That's a big hit with our 5620 users, even though it means waiting for "myx" to download after entering "layers" mode. The 630 has these features all the time, even when used with non-UNIX systems. I can't think of any way in which the 630 is inferior to the 5620..
ekrell@hector.UUCP (Eduardo Krell) (08/04/89)
In article <10665@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes: >I can't think of any way in which the 630 >is inferior to the 5620.. Well, you can't drop it from a second floor window and expect it to remain in one piece, like the 5620 did. 1/2 :-) Eduardo Krell AT&T Bell Laboratories, Murray Hill, NJ UUCP: {att,decvax,ucbvax}!ulysses!ekrell Internet: ekrell@ulysses.att.com
peter@ficc.uu.net (Peter da Silva) (08/04/89)
[ My nattering about command line editing in the terminal and escapes for turning it on and off deleted ] In article <9729@alice.UUCP>, debra@alice.UUCP (Paul De Bra) writes: > Yep, you just reinvented the jerq, blit, 5620 (or whatever generation) > terminal.... Yes, I was thinking about them. But they have no raw-mode capability, right? You can't run vi on a blit, nesspah? Besides, the windowing is overkill. Nice, but overkill. -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Business: peter@ficc.uu.net, +1 713 274 5180. | "The sentence I am now Personal: peter@sugar.hackercorp.com. `-_-' | writing is the sentence Quote: Have you hugged your wolf today? 'U` | you are now reading"
guy@auspex.auspex.com (Guy Harris) (08/05/89)
>Special terminal ioctl's to turn echo on and off >(you wouldn't want half-duplex while typing a password), etc. No, you don't, but you don't want to have to rewrite programs that use the boring old standard "ioctl"s, either; the driver should simply recognize TIOCSETP, or TCSETA, or whatever your system has, setting or clearing the ECHO flag. (I don't count those as "special", since they've been in UNIX since time immemorial, or at least since 1979/1980 or so; I interpret "special" there as meaning "something other than one of the common UNIX 'ioctl's for that purpose.")
rbj@dsys.ncsl.nist.gov (Root Boy Jim) (08/05/89)
? From: "David F. Carlson" <dave@micropen> ? The *wrong* place for command line editing is in the terminal driver. ? Kernel is for what is difficult or impossible to do in user space. Keep it ? clean and small. Too late. ? David F. Carlson, Micropen, Inc. ? micropen!dave@ee.rochester.edu ? "The faster I go, the behinder I get." --Lewis Carroll "The faster we go, the rounder we get." --Grateful Dead Root Boy Jim Have GNU, Will Travel.
debra@alice.UUCP (Paul De Bra) (08/05/89)
In article <10665@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes: }In article <9729@alice.UUCP> debra@alice.UUCP () writes: }>We could hardly believe our eyes when we discovered that this local command }>line editing went away in the new and "improved" AT&T 630 MTG terminal. (sigh) } }Well you shouldn't believe your eyes! The 630 firmware, unlike the 5620 }which was comparatively "plain", supports mouse-driven cut, paste, and }send. I use it continually. It's not quite like Rob's "mux" interface, }alas, but the capability's there. I don't know the 5620 firmware, only Rob's "mux" interface. On the 630 I cannot type a command, say "ls file", then click before the "f", type "-l", click at the end of the line, press return and have the shell execute "ls -l file". That's what I mean by local command line editing, and that's not possible on the 630 because it operates in full duplex. }... }The 630 has these features all the time, even when used with }non-UNIX systems. I can't think of any way in which the 630 }is inferior to the 5620.. I could, but comp.unix.questions is not the forum for this discussion. Paul. -- ------------------------------------------------------ |debra@research.att.com | uunet!research!debra | ------------------------------------------------------
gwyn@smoke.BRL.MIL (Doug Gwyn) (08/06/89)
In article <5527@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: >You can't run vi on a blit, nesspah? Of course you can. >Besides, the windowing is overkill. Nice, but overkill. Funny, just the other day I commented to my officemate that it was hard to imagine ever getting along without multiple windows.
debra@alice.UUCP (Paul De Bra) (08/07/89)
In article <2333@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes: >>Special terminal ioctl's to turn echo on and off >>(you wouldn't want half-duplex while typing a password), etc. >No, you don't, but you don't want to have to rewrite programs that use >the boring old standard "ioctl"s, either; the driver should simply >recognize TIOCSETP, or TCSETA, or whatever your system has, setting or >clearing the ECHO flag... It does. The "mux" terminal interface program does indeed turn the boring old standard ioctls into the special terminal-ioctls that tell the 5620 to stop echoing stuff. The programs on the Unix side don't notice any difference. Mux takes care of everything. Paul. -- ------------------------------------------------------ |debra@research.att.com | uunet!research!debra | ------------------------------------------------------
dmt@PacBell.COM (Dave Turner) (08/07/89)
In article <9747@alice.UUCP> debra@alice.UUCP () writes: >In article <10665@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes: >}In article <9729@alice.UUCP> debra@alice.UUCP () writes: >}>We could hardly believe our eyes when we discovered that this local command >}>line editing went away in the new and "improved" AT&T 630 MTG terminal. (sigh) >I don't know the 5620 firmware, only Rob's "mux" interface. >On the 630 I cannot type a command, say "ls file", then click before the >"f", type "-l", click at the end of the line, press return and have >the shell execute "ls -l file". That's what I mean by local command line >editing, and that's not possible on the 630 because it operates in full >duplex. Your 5620 and 630 operate differently than mine. My 630 allows command editing the way your 5620 does; none of my 5620s do this. The 630 has a built-in editor that allows clicking to insert or delete characters; the 5620 does not. I'd appreciate it if you'd tell me how I can upgrade my 5620s to work like yours. I'm using SVR2.1.0, SVR3.1.1 and SVR3.2 with layers. -- Dave Turner 415/542-1299 {att,bellcore,sun,ames,decwrl}!pacbell!dmt
gwyn@smoke.BRL.MIL (Doug Gwyn) (08/08/89)
In article <9747@alice.UUCP> debra@alice.UUCP () writes: >I don't know the 5620 firmware, only Rob's "mux" interface. >On the 630 I cannot type a command, say "ls file", then click before the >"f", type "-l", click at the end of the line, press return and have >the shell execute "ls -l file". That's what I mean by local command line >editing, and that's not possible on the 630 because it operates in full >duplex. On the 630, you can perform a similar local edit, snarf the edited line (newline not yet having been typed), type line-erase so that UNIX doesn't see the characters already typed, then send the snarfed edited line. "mux" maintains a record of the last-output point and doesn't send anything at all to UNIX until a newline is typed somewhere beyond the last-output point, which is why you don't have to clear the already-typed stuff out of the UNIX terminal handler before sending the revised input line when using "mux"; otherwise the operations are essentially the same. There's nothing I know of about the 630 that prevents "mux" from being implemented for it as well as the 5620. It should be a fairly easy porting job, the 630 being basically an augmented 5620 based on an MC68xxx (like the Blit) instead of a WE32xxx.
gwyn@smoke.BRL.MIL (Doug Gwyn) (08/08/89)
In article <4915@ptsfa.PacBell.COM> dmt@PacBell.COM (Dave Turner) writes: [talking to alice!debra] >I'd appreciate it if you'd tell me how I can upgrade my 5620s to work >like yours. I'm using SVR2.1.0, SVR3.1.1 and SVR3.2 with layers. Get the "dmd-pgmg" package from the AT&T UNIX System ToolChest; it includes sources for Dave Prosser's "myx", which downloads into the 5620 to replace the native firmware terminal emulator with one much more like "mux". Of course you need the DMD host support software (Core & Development packages) in order to compile and download "myx".