From mboxrd@z Thu Jan 1 00:00:00 1970 Message-Id: <200008022119.RAA07806@cse.psu.edu> To: 9fans@cse.psu.edu Subject: Re: [9fans] pipefile From: "rob pike" Date: Wed, 2 Aug 2000 17:19:35 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Topicbox-Message-UUID: f301cd4e-eac8-11e9-9e20-41e7f4b1d025 > I think he was thinking of the v2 edition where, with ktrans, you > could hit a ctrl seq and switch into different modes. I assume that > functionality was always part of ktrans itself, in other words after it's > started it is always running and handles whether or not to do translation. I thought the problem was not how to implement the translation, but how to inject it into the input stream. Thus I wrote pipefile, with the belief that someone would write the obvious bytestream converter, with or without modes, that would convert a standard keyboard into some other style of input. With pipefile, you can add any translation you want to /dev/cons. The program you write - the argument to -r - can do anything it wants, including switching between languages. Unlike with /dev/kbd, the mode won't be per window if you start it under rio, but you can start it in each window instead, if that's really what you want. /dev/kbd may seem more natural, but the idea that an arbitrary program can wake up at any time and inject characters into my input stream is too distasteful for me. That's why I didn't put /dev/kbd into rio, hoping something better (or at least safer) would come along. Pipefile may not be as convenient, but it's much safer because you must explicitly create the process; there's nothing like /dev/kbd hanging around ready to receive random characters. -rob