Re: [Freedos-devel] Re: How to detect if fd #0/#1 are the local console
Hi! 4--2004 16:47 [EMAIL PROTECTED] (Eric Auer) wrote to [EMAIL PROTECTED]: EA Hi! I suggest using isatty: EA write(isatty(1) ? 1 : 2, format (YES/NO)? , 17); EA The above example would show the confirm prompt on STDERR if STDOUT is EA redirected to a non-tty. There may be trouble with redirection to NUL, which is also device. As I post earlier, Eugeny Roshal checks if ioctl(1,0) == 0x83 (but I suggest, that enough to test 0x82). EA I guess CTTY devices are always TTYs, though. EA By the way, as far as I know, *only* COMn/AUX/CON can be CTTY targets. EA Now about CLS/... handling: Because CTTY is handled by FreeCOM itself, No. FreeCOM may be _re_called (for example, by system()) with already redirected handles by parent shell. --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Re: How to detect if fd #0/#1 are the local console
Hi! 5--2004 12:03 [EMAIL PROTECTED] (Steffen Kaiser) wrote to [EMAIL PROTECTED] [EMAIL PROTECTED]: Matthias once wrote a long mail saying how other DOSes deal with this. SK He writes that DR DOS issues ANSI escape sequences. Actually they are fine, [...] SK in http://marc.theaimsgroup.com/?l=freedos-devm=101742333130155w=2 SK If STDOUT does correspond with a device (bit 7) which does *not* SK supporting INT 29h (bit 3 cleared), it will use a method partially SK similar to the DR-DOS INT 10h/AH=00h method to clear the screen, in SK all other cases it will simply issue the ANSI ED-sequence. This is strange, because fastcon bit (0x10) usually not set for non-local devices (thus, above describes using INT10 on, say, COMx). For example, currently all devices in my environment contains no 0x10 bit, except CON. And neither device contains ANSI support (thus sending ANSI sequence to this CON is useless). --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Re: How to detect if fd #0/#1 are the local console
Hi Tom, The only reliable way is to trap int10, write a character using int21 and see if it gets trapped. I've seen (N)ANSI.SYS implementations doing direct screen IO. You're quite right about that so this is not good. however: talking about CLS, why not 1'st) write ESC J (or similar) 2'nd) clear the screen, using BIOS. ALL screens will be blank then - as intended. No, if the output goes to COM1 and not CON then the screen should be cleared on COM1 and not CON. Keep it simple, checking two bits ought to be enough: ax=4400, bx=1, int21 if (ax 0x80) /* device */ if (ax 0x10) /* fastcon */ use bios (int10) else use escape sequences else /* file */ do nothing MS COMMAND.COM actually does: INT2F at 8d5e:3397: AX=1a00, BX=3391, CX=, DX=867e, DS=8d5e, ES=8d5e INT21 (0) at 8d5e:33aa: AX=440c, BX=0001, CX=037f, DX=db6f, DS=8d5e, INT21 (0) at 8d5e:33c0: AX=4400, BX=0001, CX=037f, DX=db6f, DS=8d5e, INT10 (see also my previous email what happens if you clear the fastcon bit) But NANSI.SYS doesn't support int2f/AX=1a00 or the device driver ioctl corresponding to 440C, so the first two aren't that important -- on a local display we can use int10 anyway. Bart --- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Re: How to detect if fd #0/#1 are the local console
Hi Steffen, But back to the question: HOW DOES FREECOM KNOW THAT THE CURRENT STANDARD OUTPUT IS THE DEVICE DRIVEN BY THE BIOS? Is it save / useful to use BIOS functions. Or how can FreeCOM ensure the human sitting on the other side of the line is seeing the results. The only reliable way is to trap int10, write a character using int21 and see if it gets trapped. Very dirty as you'll have to send a backspace in case there really is a terminal on the other side (otherwise you'd get the character displayed). That said. In practice a console driver will have the FAST int29 bit set, and a COM driver won't. As int29 will surely write a character to the console. This isn't waterproof in theory but ... I simply don't know of any who don't (and in the rare theoretical case where a CON driver doesn't use int29 one could just as well treat it as a dumb terminal anyway). When I saw your mail I had this deja vu feeling we get here on this list much more often ;) Matthias once wrote a long mail saying how other DOSes deal with this. http://marc.theaimsgroup.com/?l=freedos-devm=101742333130155w=2 just follow the whole thread (prev and next), there's nothing I can add here, but I assumed you had already looked this up? Bart --- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Re: How to detect if fd #0/#1 are the local console
On Thu, 5 Aug 2004, Bart Oldeman wrote: Hello Bart, But back to the question: HOW DOES FREECOM KNOW THAT THE CURRENT STANDARD OUTPUT IS THE DEVICE DRIVEN BY THE BIOS? Is it save / useful to use BIOS functions. Or how can FreeCOM ensure the human sitting on the other side of the line is seeing the results. The only reliable way is to trap int10, write a character using int21 and Yeah, that's what I thought of. And there is also some nice try for stdin ;-). That said. In practice a console driver will have the FAST int29 bit set, and a COM driver won't. As int29 will surely write a character to the console. This isn't waterproof in theory but ... I simply don't know of When I saw your mail I had this deja vu feeling we get here on this list much more often ;) Well, this thread deals with CLS in particular. However, my reasoning goes further than that, e.g. the enhanced input needs to position the cursor all over the line, which probably spans multiple physical lines. And Cursor_Left (ASCII 0x08) does not necessarily wrap to the previous (physical) line. Matthias once wrote a long mail saying how other DOSes deal with this. Hmm. I'm curious. He writes that DR DOS issues ANSI escape sequences. Actually they are fine, as long as you have a VT100 provider installed, as I wrote. But it is impossible to detect such provider across a line on another computer. Also, in http://marc.theaimsgroup.com/?l=freedos-devm=101717593306186w=2 he writes /If/ an ANSI (or another extended console) driver is installed and detected (which is not trivial, if it should work with all known ANSI drivers), the command processor will send an ANSI-ED sequence [2J to STDOUT (whereby stands for ESC (1Bh) here). Then: Only if no such driver is around and the console is attached to the physical screen (not redirected, no CTTY), in http://marc.theaimsgroup.com/?l=freedos-devm=101742333130155w=2 If STDOUT does correspond with a device (bit 7) which does *not* supporting INT 29h (bit 3 cleared), it will use a method partially similar to the DR-DOS INT 10h/AH=00h method to clear the screen, in all other cases it will simply issue the ANSI ED-sequence. The INT 10h method used appears to work more So, if STDOUT == COM3 (no Fast Output bit) and the shell does not know about a CTTY COM3 (where should it get the info about it unless the CTTY command was invoked in the shell itself?). it uses the BIOS. My claim is: a) you cannot detect an ANSI driver across the line **), and b) you do not know for sure what CTTY is in place, except the shell itself has invoked it ***). So, what is described there means: if the server computer has ANSI installed locally, it will send ANSI tokens to your client, regardless if your client has ANSI or not; if the shell on the server has not executed the CTTY command itself, it will clear the server's screen through the BIOS. This is what I wrote and what I asked about. When I now move the issue away from CLS toward the enhanced input, I have the problem to freely position the cursor in a long line wrapping upon several physical lines. Actually I seem to be stuck in a problem that cannot be solved automatically, but by the user only, e.g. by setting environment variables or some flags as it is common in Unix shells (TERM=, ROWS=, LINES=, setterm). If one could assume that a VT100 parser is present, the problems would be less. just follow the whole thread (prev and next), there's nothing I can add here, but I assumed you had already looked this up? No, I have no luck using any search engine in conjunction with any FreeDOS archive. Bye, === **) No sample in the messages list a possibility to detect an ANSI driver on the other end of a COM line. ***) Only the hint about device/stdout/fastput. -- Steffen Kaiser --- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Re: How to detect if fd #0/#1 are the local console
On Thu, 5 Aug 2004, Steffen Kaiser wrote: a) you cannot detect an ANSI driver across the line **), and b) you do not know for sure what CTTY is in place, except the shell itself has invoked it ***). True. And now my opinion is that you can only assume that a VT100-style terminal is in place across the line i.e. a simple if (int29 unsupported) or (ANSI.SYS is installed locally), then use VT100 style Esc sequences. What's on the other end of the line simply has to be some form of terminal -- ANSI driver installed may be nonsensical. A DOS machine would probably more often let a communications program such as Telix do the parsing instead. In practical cases (except for some really ancient hardware terminals) the escape sequences will be VT100 style, and without any terminfo databases it's the best you can assume. Quote from: in http://marc.theaimsgroup.com/?l=freedos-devm=101742333130155w=2 If STDOUT does correspond with a device (bit 7) which does *not* supporting INT 29h (bit 3 cleared), it will use a method partially similar to the DR-DOS INT 10h/AH=00h method to clear the screen, in all other cases it will simply issue the ANSI ED-sequence. The INT 10h method used appears to work more So, if STDOUT == COM3 (no Fast Output bit) and the shell does not know about a CTTY COM3 (where should it get the info about it unless the CTTY command was invoked in the shell itself?). it uses the BIOS. I'm a bit suspicious about this bit -- IMHO it's logical to use ANSI sequences only if this bit is *not* set (i.e. the other way around). If the bit is set then it doesn't mean an ANSI driver is installed: the default CON driver in any DOS I know already uses int29 and has this bit set, so outputting ANSI sequences if the bit is set would be plain wrong. Testing with MSDOS 7.10 without ANSI.SYS. Here int21/ax=4400 gives attributes 0x80d3, i.e. device, int29, stdout, stdin. Now clear bit 4 by setting int21/ax=4401/bx=0/dx=c3. Do a CLS What I see is: ESC[2J (where ESC is that - arrow I can't type here) So Matthias had things exactly the wrong way around I think. Bart --- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Re: How to detect if fd #0/#1 are the local console
On Wed, 4 Aug 2004 16:47:42 +0200 (MEST), you wrote: Hi Everybody, write(isatty(1) ? 1 : 2, format (YES/NO)? , 17); I remember many years ago there's a development tools ASYNC PROFESSIONAL, anyone interested to build a similar free version? Rgds, Johnson. --- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
