chris@mimsy.UUCP (Chris Torek) (10/08/88)
In article <13215@hqda-ai.ARPA> jay@hqda-ai.ARPA (Jay Hiser) writes: >... but SysV vi has an interesting bug/feature that can cause a problem. > >CCI, our SysV vender, has just posted a bulletin warning that vi has >an undocumented feature. "[it was] designed to look for the >occurrence of a line that starts with the string "ei:" and use the >characters following the ei: as editor commands. This is NOT >documented." This bulletin is correct in point of fact but is wrong in spirit. What really happens is that vi is looking for `mode lines' consisting of `ex:<commands>' or `vi:<commands>'. Such lines must appear within the first or last 5 (10?) lines of the file being edited. Now, the code that checks for `mode lines' is rather sloppy. Not only does it match on `ex' and `vi', it also matches on `ei' and `vx'. And in 4.2BSD (and perhaps some SysV releases---no telling which ones since the release numbering is so bizarre) you cannot turn it off! More modern vi's have a `modeline' option, so that you must `set modeline' before editing such a file if you want mode line commands to take effect. `set nomodeline' in your .exrc or $EXINIT or ./.exrc and the editor will ignore mode line commands. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
bak@csd-v.UUCP (Bruce A. Kern) (10/09/88)
>In article <13215@hqda-ai.ARPA> jay@hqda-ai.ARPA (Jay Hiser) writes: >>... but SysV vi has an interesting bug/feature that can cause a problem. >> [description of modeline follows...] > >Now, the code that checks for `mode lines' is rather sloppy. Not only >does it match on `ex' and `vi', it also matches on `ei' and `vx'. And >in 4.2BSD (and perhaps some SysV releases---no telling which ones since >the release numbering is so bizarre) you cannot turn it off! More modern >Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris Just a note to report that the entire feature seems to be absent in the Microport V/AT 2.3-U version of vi. Executing :set all inside vi reports nothing about a [no]modeline option and editing the following file: 0 ex:% s/0/abc/ 1 2 3 4 ex:% s/0/abc/ produces nothing interesting. -- Bruce A. Kern 1-203-270-0399 Computer Systems Design Voice: 730 - 1700 Mon. thru Fri. 29 High Rock Road Data: All other times Sandy Hook, Ct. 06482
morrell@hpsal2.HP.COM (Michael Morrell) (10/11/88)
/ hpsal2:comp.bugs.sys5 / bak@csd-v.UUCP (Bruce A. Kern) / 7:36 pm Oct 8, 1988 / editing the following file: 0 ex:% s/0/abc/ 1 2 3 4 ex:% s/0/abc/ produces nothing interesting. ---------- You need to follow the command with another ":". Also, the space seems to confuse my vi. Try the following: 0 ex:%s/0/abc/: 1 2 3 4
rsj@wa4mei.UUCP (Randy Jarrett WA4MEI) (10/11/88)
In article <13905@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes: >This bulletin is correct in point of fact but is wrong in spirit. >What really happens is that vi is looking for `mode lines' consisting >of `ex:<commands>' or `vi:<commands>'. Such lines must appear within >the first or last 5 (10?) lines of the file being edited. That explains the problems that I have been having while makeing changes with vi to my password file. I have an entry that I use my ham call sign wa4mei and in the password file it has a ':' at the end (wa4mei:...). everytime vi comes up it gives me a bunch of gobbly gook about not being valid vi commands. I am running Microport 2.3U on a 286. It doesn't cause any problems, just annoying. Sure drove a bunch of the wizards around here bonkers for a while. -- Randy Jarrett WA4MEI UUCP ...!gatech!wa4mei!rsj | US SNAIL: P.O. Box 941217 PHONE +1 404 493 9017 | Atlanta, GA 30341-0217
tanner@ki4pv.uucp (Dr. T. Andrews) (10/12/88)
In article <176@csd-v.UUCP>, bak@csd-v.UUCP (Bruce A. Kern) writes:
) Just a note to report that the entire [modelines] feature seems to
) be absent in the Microport V/AT 2.3-U version of vi.
The same misfeature is present in most (all?) xenix releases.
Talking to the vendors provides the information that "vi" is crippled
that way for your own good.
They just comment out the relevant code. No, they won't slide you
a fully-functional "vi" (perhaps with "modeline" turned off by
default). For your own good. And no, you can't buy just the source
to "vi" from them. (Hey, they have to enhance the basic UN|X product
in some way: this is a proprietary enhancement!)
SCO, Intel, and Microport customers: you should be pleased that their
vendors know your needs, perhaps better than you do yourself.
--
...!bikini.cis.ufl.edu!ki4pv!tanner ...!bpa!cdin-1!cdis-1!ki4pv!tanner
or... {allegra killer gatech!uflorida decvax!ucf-cs}!ki4pv!tannerjohn@frog.UUCP (John Woods) (10/16/88)
In article <7052@ki4pv.uucp>, tanner@ki4pv.uucp (Dr. T. Andrews) writes: > In article <176@csd-v.UUCP>, bak@csd-v.UUCP (Bruce A. Kern) writes: > ) Just a note to report that the entire [modelines] feature seems to > ) be absent in the Microport V/AT 2.3-U version of vi. > > The same misfeature is present in most (all?) xenix releases. > Talking to the vendors provides the information that "vi" is crippled > that way for your own good. > Another vendor that supplies this "crippled" vi is AT&T. The System V Release 2.0 source tape, straight from AT&T, which we have here does not have this hell-spawned modelines feature. First we have someone who claimed that files with lines longer than 512 characters are not "text" files because vi can't edit them. Now we find that password files containing users whose name ends in "ex" aren't "text" files either. Yet another feature added without any thought whatsoever. Consider by contrast the various EMACSen (in particular GNU EMACS) which allow you to set the major modes for editing with distinctive strings like -*- Text -*- but DON'T try to interpret random nonsense as editor commands just because you got the 1 in 3600 occurance of an encrypted password ending in "ex" (for those VI-philes who are going to argue that you should just avoid login names like w3mex or whatever it was)... -- John Woods, Charles River Data Systems, Framingham MA, (617) 626-1101 ...!decvax!frog!john, john@frog.UUCP, ...!mit-eddie!jfw, jfw@eddie.mit.edu Goooooood Morning Discovery! -Robin Williams Abracadabra, 'press to MECO', America is back in space!
guy@auspex.UUCP (Guy Harris) (10/18/88)
> Another vendor that supplies this "crippled" vi is AT&T. The System V > Release 2.0 source tape, straight from AT&T, which we have here does not > have this hell-spawned modelines feature. S5R3's "vi", as I remember, has modelines. Both it and the 4.3BSD version have a flag to disable it (although I think the flag's name differs slightly between the two versions, sigh).
jlh@loral.UUCP (Physically Pffft) (10/19/88)
In article <1221@X.UUCP> john@frog.UUCP (John Woods) writes: >Release 2.0 source tape, straight from AT&T, which we have here does not >have this hell-spawned modelines feature. Actually, I was one very happy camper when I discovered the modeline feature. Different people use different tab settings and using modeline is a pretty painless way to let anybody with any default setting go in and edit any file. There are also some files where I want ignorecase turned off, while I want it on 95% of the time. Yes, I know its a security hole. But it's such a damned useful little hole..... Jim "In case of immenent nuclear destruction, I'll be in the Oreo aisle" -- Jim Harkins Loral Instrumentation, San Diego {ucbvax, ittvax!dcdwest, akgua, decvax, ihnp4}!ucsd!sdcc6!loral!jlh
wu@spot.Colorado.EDU (WU SHI-KUEI) (10/19/88)
In article <1857@loral.UUCP> jlh@loral.UUCP (Physically Pffft) writes: >..... There are also some files where I want ignorecase turned off, while >I want it on 95% of the time. Curiousity has gotten the better of me and unfortunately I cannot send replies from this machine .... but why turn on ignorecase? In the six or seven years I have used and taught vi I have never heard of anyone using this feature and would appreciate what Jim Harkins' (and anyone else's) motivation is for turning it on. Thank you. Just a guest here. In real life Carl Brandauer attmail!bdaemon!carl uunet!nbires!bdaemon!carl
karl@haddock.ima.isc.com (Karl Heuer) (10/20/88)
In article <1221@X.UUCP> john@frog.UUCP (John Woods) writes: >just because you got the 1 in 3600 occurance of an encrypted password ending >in "ex" ... A password encrypted with the usual algorithm will never end in "ex" or "vi". As a side effect of packing 64 bits of password into 11 six-bit characters, the final character is always one of [.26AEIMQUYcgkosw]. Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint
mark@applix.UUCP (Mark Fox) (10/20/88)
In article <4151@boulder.Colorado.EDU> wu@spot.Colorado.EDU (WU SHI-KUEI) writes: >In article <1857@loral.UUCP> jlh@loral.UUCP (Physically Pffft) writes: >>..... There are also some files where I want ignorecase turned off, while >>I want it on 95% of the time. > >.... but why turn on ignorecase? We have people here who like to name their C variables with mixed case, e.g., windowId instead of window_id or wid. The X windows interface functions are also mixed case. Furthermore, we strongly encourage our people to capitalize the first letter of globals. The people who wrote the Proximity dictionary utilities also share that practice. Therefore, if I am looking for a variable, if I set ignorecase, I don't have to remember what case it was typed in with. (Let's see is it windowId, WindowID, or ...) Very helpful when looking at other peoples' code. -- Mark UUCP: ...harvard!m2c!applix!mark mark@applix.m2c.org
jlh@loral.UUCP (Physically Pffft) (10/21/88)
In article <4151@boulder.Colorado.EDU> wu@spot.Colorado.EDU (WU SHI-KUEI) writes: >Curiousity has gotten the better of me and unfortunately I cannot send replies >from this machine .... but why turn on ignorecase? In the six or seven years >I have used and taught vi I have never heard of anyone using this feature and >would appreciate what Jim Harkins' (and anyone else's) motivation is for >turning it on. > Because I'm lazy and would rather just type in what I want to look for without messing with shift keys. And in text files I don't like worrying about whether or not my word is the start of a sentance, in which case the first letter is capitalized. I've actually gotten so used to having it I get upset when forced to use an editor without this feature. Does anyone know of a way to have the search operation always respect the case? Just this morning I edited lots of files where I wanted to change the string 'vax' to 'simulate' but leave the string 'VAX' unchanged. I sure got tired of typing in ':set noic' everytime I found a file that needed a change, and then having my regular searches fail due to ignorecase being turned off. Jim PS. It's been brought to my attention the signature below is out of date. I'll fix it when I have time. -- Jim Harkins jlh@loral.cts.com may work. Loral Instrumentation, San Diego {ucbvax, ittvax!dcdwest, akgua, decvax, ihnp4}!ucsd!sdcc6!loral!jlh
terryl@tekcrl.CRL.TEK.COM (10/21/88)
In article <4151@boulder.Colorado.EDU> wu@spot.Colorado.EDU (WU SHI-KUEI) writes: >In article <1857@loral.UUCP> jlh@loral.UUCP (Physically Pffft) writes: >>..... There are also some files where I want ignorecase turned off, while >>I want it on 95% of the time. > >Curiousity has gotten the better of me and unfortunately I cannot send replies >from this machine .... but why turn on ignorecase? In the six or seven years >I have used and taught vi I have never heard of anyone using this feature and >would appreciate what Jim Harkins' (and anyone else's) motivation is for >turning it on. >Carl Brandauer Ah, Mr. Brandauer, you have obviously not worked with an object-oriented language, or with people whose main work is with object-oriented languages but do program in other languages. You see, it's sort of a common occurence in object-oriented languages to capitalize(capitilize?) the first letter in each word of a variable (i.e. if you had a variable called `thisisavariable', it would consist of four words "this is a variable", and would be written as thus: ThisIsAVariable); BUT (you know, there's always a BUT!! (-:), one does not capitalize the very first word in a variable if it's a class variable (or is it not capitalized if it's an instance variable, or is it something else??? I could never remember....). The point being is that this common occurence is so deeply ingrained in object-oriented languages (especially Smalltalk(TM)), that people whose main work in object-oriented carry it over when they program in other languages. I have worked exstensively with people with an object-oriented background but still do a fair amount of programming in C(TM, I assume!!), and when I edit these files, I do want ignorecase turned on. In the other 95% of the time, like Mr. Harkins said, I want it turned off..... Also, it's such a drag to work on a file that's been created on a VMS system that's somehow found its way onto a UNIX system (since VMS use caps for EVERYTHING!!! (Insert MANY (-: here)). Since I'm too lazy to keep hitting the <SHIFT> key, I'll just turn on ignorecase.....
tanner@ki4pv.uucp (Dr. T. Andrews) (10/22/88)
In article <1857@loral.UUCP>, jlh@loral.UUCP (Physically Pffft) writes:
) I want [modelines] on 95% of the time. Yes, I know its a security
) hole. But it's such a damned useful little hole.....
The clever thing to do, then, would be to close the security hole.
Refuse to pass "!" commands from modelines. Leave the useful
functionality (file configures editor properly) in place.
--
...!bikini.cis.ufl.edu!ki4pv!tanner ...!bpa!cdin-1!cdis-1!ki4pv!tanner
or... {allegra killer gatech!uflorida decvax!ucf-cs}!ki4pv!tannerguy@auspex.UUCP (Guy Harris) (10/25/88)
>) I want [modelines] on 95% of the time. Yes, I know its a security >) hole. But it's such a damned useful little hole..... > >The clever thing to do, then, would be to close the security hole. >Refuse to pass "!" commands from modelines. Leave the useful >functionality (file configures editor properly) in place. *AND* provide some way for a user to shut modelines OFF, just in case they DON'T like getting surprised by random commands being executed by the editor just because a character sequence that looks like a modeline happens to be in the file.... (Both 4.3BSD and S5R3 provide this; there's an option that has to be "on" in order for "ex"/"vi" to recognize modelines. Unfortunately, 4.3BSD calls it "modeline" and S5R3 calls it "modelines"....)
mmengel@cuuxb.ATT.COM (Marc W. Mengel) (10/28/88)
In article <1221@X.UUCP> john@frog.UUCP (John Woods) writes: >>[Xenix omits the "set modeline" option, and executes ex:...: strings ] >Another vendor that supplies this "crippled" vi is AT&T. The System V >Release 2.0 source tape, straight from AT&T, which we have here does not >have this hell-spawned modelines feature. Wait a minute... while it is true that AT&T vi/ex does not have the "set modeline" command, it also does not interpred ex:...: strings in the text of a file (i.e. you don't *need* the set modeline command). Of course, I looked at Sys.Vr.3, which is what we are running here, Sys.Vr.2 might have inadvertently included that "feature" when they ported from BSD... >-- >John Woods, Charles River Data Systems, Framingham MA, (617) 626-1101
wu@spot.Colorado.EDU (WU SHI-KUEI) (10/28/88)
In article <2146@cuuxb.ATT.COM> mmengel@cuuxb.UUCP (Marc W. Mengel) writes: >>Another vendor that supplies this "crippled" vi is AT&T. The System V >>Release 2.0 source tape, straight from AT&T, which we have here does not >>have this hell-spawned modelines feature. Our 3B2/400 running SVr3.1 support set modelines[s] and honors ex: and all it's variants. YECH Carl Brandauer - uunet!nbires!bdaemon!carl
guy@auspex.UUCP (Guy Harris) (10/29/88)
>Wait a minute... while it is true that AT&T vi/ex does not have >the "set modeline" command, it also does not interpred ex:...: >strings in the text of a file (i.e. you don't *need* the set >modeline command). Of course, I looked at Sys.Vr.3, which is what >we are running here, Sys.Vr.2 might have inadvertently included that >"feature" when they ported from BSD... 1) The "feature" to which they were referring was the interpretation of "ex:" strings, not the "modeline" flag to shut that off. 2) I'm not sure whether S5R2 had modelines; S5R3 definitely does (I looked at the source).
guy@auspex.UUCP (Guy Harris) (10/29/88)
>-Wait a minute... while it is true that AT&T vi/ex does not have >-the "set modeline" command, it also does not interpred ex:...: >-strings in the text of a file (i.e. you don't *need* the set >-modeline command). > >Hurray -- a "Berkeley bug" fixed by AT&T. Not so fast, Doug. It's more like a Berkeley misfeature that AT&T hadn't picked up yet; S5R3 has it.
john@frog.UUCP (John Woods) (10/30/88)
In article <2146@cuuxb.ATT.COM>, mmengel@cuuxb.ATT.COM (Marc W. Mengel) writes: > In article <1221@X.UUCP> john@frog.UUCP (John Woods) writes: > >>[Xenix omits the "set modeline" option, and executes ex:...: strings ] > >Another vendor that supplies this "crippled" vi is AT&T. The System V > >Release 2.0 source tape, straight from AT&T, which we have here does not > >have this hell-spawned modelines feature. > Wait a minute... while it is true that AT&T vi/ex does not have > the "set modeline" command, it also does not interpred ex:...: > strings in the text of a file (i.e. you don't *need* the set > modeline command). Alpha particles must have corrupted my mind at the time. This was the state that I intended to describe--no magic strings, no way of disabling the misfeature. Oops. In article <8786@smoke.BRL.MIL>, gwyn@smoke.BRL.MIL (Doug Gwyn ) writes: >In article <2146@cuuxb.ATT.COM> mmengel@cuuxb.UUCP (Marc W. Mengel) writes: >-Wait a minute... while it is true that AT&T vi/ex does not have >-the "set modeline" command, it also does not interpred ex:...: >-strings in the text of a file (i.e. you don't *need* the set >-modeline command). > >Hurray -- a "Berkeley bug" fixed by AT&T. And so amazing that it was just simply by removing code. Actually, I am not at all amazed... -- John Woods, Charles River Data Systems, Framingham MA, (617) 626-1101 ...!decvax!frog!john, john@frog.UUCP, ...!mit-eddie!jfw, jfw@eddie.mit.edu Goooooood Morning Discovery! -Robin Williams Abracadabra, 'press to MECO', America is back in space!