gill@sfsup.UUCP (Timothy D. Gill) (12/14/88)
We have an existing user interface tool, one that runs (more or less) in raw mode, that uses ^Z to do the operation "goto command line" and we want to change it because of a conflict with the use of ^Z for the SUSPEND line discipline character for BSD-style job control. Our only choices are ^C and ^J because all other control characters are used by the tool already. ^C seems like it should be avoided because it is often used as the INTERRUPT character in BSD and has a similar meaning in MS-DOS and other operating systems. ^J does not seem to be used in UNIX applications, possibly because of its association with ^M (return) and the mapping that line discipline usually performs with those two characters. However, we can, given our use of raw mode, distinguish between ^J and ^M, and it works. What are the historical or cultural reasons that ^J is not used in UNIX tools? Is there a strong reason not to use it now?
gwyn@smoke.BRL.MIL (Doug Gwyn ) (12/14/88)
In article <4404@sfsup.UUCP> gill@sfsup.UUCP (Timothy D. Gill) writes: >we want to change it because of a conflict with the use of ^Z for >the SUSPEND line discipline character for BSD-style job control. Note that you can disable or change that special character in the new-tty handler, permitting its continued use in your application. >Our only choices are ^C and ^J because all other control characters >are used by the tool already. Ouch. What are you going to do when you need to add another function? This might be a good time to figure that out. >What are the historical or cultural reasons that ^J is not used in UNIX >tools? Is there a strong reason not to use it now? ^J (ASCII LF) is, of course, the character UNIX uses in text files and streams to denote "new line". Depending on the terminal handler modes, a received CR may be mapped into LF (also there are some options concerning how CR and LF are echoed). Some terminals don't have CR, just NL (same code as LF).
guy@auspex.UUCP (Guy Harris) (12/15/88)
>What are the historical or cultural reasons that ^J is not used in UNIX >tools? There *are* UNIX cbreak-mode or raw-mode applications that use ^J and ^M for different purposes; some versions of EMACS do (but then again they permit you to do fairly arbitrary key bindings). The main problem is if you have a terminal that can't send them both, but that's a different matter.
fyl@ssc.UUCP (Phil Hughes) (12/17/88)
In article <713@auspex.UUCP>, guy@auspex.UUCP (Guy Harris) writes: | >What are the historical or cultural reasons that ^J is not used in UNIX | >tools? > There *are* UNIX cbreak-mode or raw-mode applications that use ^J and ^M > for different purposes; some versions of EMACS do (but then again they > permit you to do fairly arbitrary key bindings). The main problem is if > you have a terminal that can't send them both, but that's a different > matter. Zebu, our records management product uses ^M to get to the next field and ^J to get to a secondary record. We have been using it this way at SSC since 1983 and have been selling it for almost as long with no problems/complaints. Did I miss something as to why this could be a problem? -- Phil Hughes, SSC, Inc. P.O. Box 55549, Seattle, WA 98155 (206)FOR-UNIX uw-beaver!tikal!ssc!fyl or uunet!pilchuck!ssc!fyl or attmail!ssc!fyl
guy@auspex.UUCP (Guy Harris) (12/17/88)
>Zebu, our records management product uses ^M to get to the next field >and ^J to get to a secondary record. We have been using it this way >at SSC since 1983 and have been selling it for almost as long with no >problems/complaints. Did I miss something as to why this could be a >problem? Well, you appear to have missed the last sentence of my statement: >> The main problem is if you have a terminal that can't send them both... I think there really are such terminals. However, most terminals don't have this problem, which is probably why you haven't had any complaints. With any luck, you never will.