GNOME Bugzilla – Bug 621187
No platform-independent way of using stdout/stdin
Last modified: 2018-05-24 12:21:43 UTC
Most platforms have some concept of standard out, standard in and standard error, but GIO doesn't abstract those. This means if I want to use a GOutputStream to stdout, I need to link to gio-unix and use a GUnixOutputStream on ~unix systems, and do whatever I need to do on Windows systems, and so on. This sucks. There should be a way of getting a GInputStream for stdin and GOutputStreams for stdout/stderr without needing platform-dependent knowledge.
It should be relatively easy to fix this, we do have GWin32InputStream and GWin32OutputStream. So just some unified wrappers that use either GUnix*Stream or GWin32*Stream is needed.
Yeah, I think the hardest bit is naming. Clearly I'm having an off day but couldn't think of a good name. :/
bug 588828 suggests "GIOConsole" for consistency with java and .NET, although some people didn't really like that. this bug might be considered more or less a dup of that anyway
It's certainly a subset of 588828, with ryan's comment: >I guess we should probably have some sort of g_input_stream_new_for_stdin() and >g_output_stream_new_for_std{out,err}() or something like that. I was hoping for some platform-agnostic names instead of stdin/stdout, but maybe they are fine.
Well, Win32 also uses roughly the same terminology, STD_INPUT_HANDLE, STD_OUTPUT_HANDLE, and STD_ERROR_HANDLE (possible parameters to GetStdHandle() and SetStdHandle()).
How about we start with something like this in ginputstream.h: #if defined (G_OS_UNIX) #include "gunixinputstream.h" #elif defined (G_OS_WIN32) #include "gwin32inputstream.h" #endif GInputStream * g_input_stream_new_for_stdin (void) { #if defined (G_OS_UNIX) return g_unix_input_stream_new (STDIN_FILENO, FALSE); #elif defined (G_OS_WIN32) return g_win32_input_stream_new (STD_INPUT_HANDLE, FALSE); #else #warning Need implementation for g_input_stream_new_for_stdin return NULL; #endif }
Actually my win32-guessing was very wrong, is this better? return g_win32_input_stream_new (GetStdHandle (STD_INPUT_HANDLE), FALSE); (maybe I should man up and read MSDN)
Looks OK to me...
Created attachment 163297 [details] [review] Draft 1 With basic comments too. If a glib maintainer can ack/nak this approach I can finish it off (header, alias, gtk-doc integration, etc).
Patch seems to have some ANSI goo in it. I'd definitely prefer seeing the console class.
I would say the *program's* standard input/output, not the system's. Also, point out that NULL is returned also if the running program doesn't have a standard input/output active (even if in general programs on the system in question do have).
Comment now reads: + * Create a new GOutputStream that writes to the program's standard output. If + * the system doesn't have the concept of standard output, or the program + * doesn't have a standard output, %NULL is returned.
If stdin/stdout point to files (rather than ttys or pipes) GUnixInput/OutputStream may behave poorly currently, so we should fix that.
Any progress on this?
(In reply to comment #12) > + * Create a new GOutputStream that writes to the program's standard output. > If > + * the system doesn't have the concept of standard output, or the program > + * doesn't have a standard output, %NULL is returned. > Drive-by question: Doesn't that mean a lot of programs are just gonna crash on those systems because nobody ever checks the return value for %NULL? Wouldn't it be better to provide some no-op stream instead?
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/glib/issues/309.