> Of course in Posix you can tell if a file is connected to a terminal with > isatty > (or _isatty in Windows).
Ouch. Need some design help on this. Before starting I note previous note that I'm really confused about why Felix textio works at all since fopen is defined for BOTH C++ and C file kinds. So now: There are THREE kinds of files to deal with: (a) Native file handles (int on Posix, HANDLE on WIndows, as well as the int kind for emulation .. grrr ..) (b) C FILE* (c) C++ streams Felix textio works with (b) and (c). However there is a minor problem: C FILE* is dynamic and can be closed. C++ istreams can't be closed. This sucks BIG TIME. You can close an fstream, but cin is not an fstream. So C++ is making type distinctions Felix doesn't, because it wants C and C++ file kinds to work the same way (but they don't :) Now to confuse things more, I copied silliness from Python and I PASS the address of cin, cout, and cerr to Felix programs in the thread frame. The idea, as in Python, is that you can redirect these, independently of the OS level crud for redirection. Also, one can view C and C++ standard I/O for input, output, and error as a design bug: they're passed implicitly to the program, and in particular it makes the code non-re-entrant because in effect they're global variables. So isolating this crap in the Felix driver seemed like a good idea at the time. However the standard textio functions don't use these variables anyhow, they use the C++ standard ones :-) So as a result of this mess there are FOUR representation of standard input (and output and error). Now, by comparison, whilst Posix file descriptor API is a complete abortion, the use of a scalar value (int) to represent the standard files means the I/O API actually IS re-entrant (because the buffers are held by the OS not the language library). So there are some questions; 1. Should I get rid of the pointers to the C++ I/O streams in the thread frame? (since I'm not using them anyhow). 2. Should the "readln" function check if the input device is a terminal, and if not, echo the read in line to standard output? The thing is, when you're line editing on a terminal the characters you type are echoed to the terminal, but this is NOT echoing to standard output. In fact on most actual terminals the characters are echoed to the screen by the terminal itself, and if you want the driver to do it, you have to turn that feature off. In either case, the echoing is at a low level (the characters don't actually go into the standard output buffer .. because that's buffered I/O and you wouldn't see them until the buffer got flushed). So we're screwed either-which-way. It probably makes more sense to actually turn off the prompt as well if it isn't a terminal! The problem is that the interaction: ~/felix>build/release/host/bin/flx --test=build/release src/web/tut_01 Hello World Hello johnskaller Hello Enter your name: me Hello me Enter your name: you Hello you! looks sane. However this is what happens when redirecting input: ~/felix>build/release/host/bin/flx --test=build/release --input=meme.input --stdout=fred.out src/web/tut_01 ~/felix>cat fred.out Hello World Hello johnskaller Hello Enter your name: Hello me Enter your name: Hello MEE!! The PROBLEM is that if I put that in the tutorial the "expect" will be correct but it will look all wrong to the reader! -- john skaller skal...@users.sourceforge.net http://felix-lang.org ------------------------------------------------------------------------------ CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments & Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk _______________________________________________ Felix-language mailing list Felix-language@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/felix-language
