Command line arguments

[Keith Thompson]

Help! It sounds so complicated that I may have to forget the whole thing,
and just make my editors etc work with the minimum set of keys that are
certain to be available. (However, the SDL looks intriguing..)

None of these facilities are provided by standard C. I suggest
comp.unix.programmer would be a better place for your questions.

Some friendly advice: Telling them that Unix has been doing things
wrong is not likely to be constructive.

 

[Geoff]

Well, there is that, too, but also a routine to automatically expand
wildcards before calling main(argc,argv). I believe back to MSC6.0
(that is, the non-visual C compiler) and about the time of QuickC.

If I remember right, you link in one extra .OBJ file and it does
everything else.

In that case I believe you might be referring to _setargv and
setargv.obj but I've never used it. It's quite possible this module is
linked to the gcc projects compiled under Windows to emulate the Unix
style shell wildcard expansion observed by the OP.

 

[Alan Curry]

This is where you lose me. I'm not interested in emulation of any sort of
terminal. I just want to read keys from my keyboard; how difficult can it
be?

I assume as a newcomer to the platform you're trying to write programs the
simplest way possible. That means using stdio, and that means you're
accessing an ASCII-based character stream. Not raw key events.

I understand that with standard line input via C's getchar() and so on, the
OS or the library will take care of basic line-editing; that's fine.

So far so good.

But moving just one step beyond that, in order to implement a console-based
editor for example, seems to have been made extraordinarily difficult for
some reason!

I can never quite understand what DOS and Windows programmers mean when they
use the word "console". In unix, the console is just a regular terminal,
which happens to be the destination for kernel messages. And it can be any
kind of terminal - it might be attached to a serial port or it might be a
remote node on the network.

The keyboard handling I want needs two kinds of key presses. Printable keys,
and control keys. They don't need to share the same code-space. I don't
expect it to work with stdin as I said above, and I don't see the need to
have to encode everything as a serial stream of ASCII codes either.

"Everything as a serial stream of ASCII codes" is a good candidate for short
statement of the unix philosophy...

Really, it's just backward compatibility. The unix culture started with
hardware terminals that sent ASCII over a serial line to a host computer, and
tons of programs were developed to use that interface.

Later when keyboards and monitors directly connected to the unix host became
common, we didn't want to throw all of our existing code away, so we retained
the old "ASCII terminal" paradigm by including an emulator in the kernel.
That's why the default Linux console is a VT100 emulator running on top of
the PC keyboard and video hardware, with your stdin and stdout connected to
the emulated serial line.

Of course there were people with dreams of fancier user interfaces, and they
built the X Window System. And on top of that they built KDE and GNOME and
other fancy stuff.

Those are the two major user interface possibilities for unix programs:
ASCII/UTF-8 stdin/stdout, or GUI on top of X11. There isn't a "middle of the
road" interface that looks like a plain text terminal but provides detailed
information about key events. Not one that's widely used at least.

Help! It sounds so complicated that I may have to forget the whole thing,
and just make my editors etc work with the minimum set of keys that are
certain to be available. (However, the SDL looks intriguing..)

Did you know there are approximately 17 zillion text editors already? Can you
really hate *all* of them enough to justify adding another?

The minimum set of keys that are certain to be available on all terminals is
the printable ASCII set. Actually, probably less than that. Somebody out
there might still have a functioning uppercase-only terminal.

 

[James Dow Allen]

I've just discovered that a single command line argument containing
wildcards, such as *.c, is expanded to a full list of matching files before
it gets to main().

Am I the only one annoyed that in Linux
cp none*
produces
cp: No match
?? It implies, falsely that the message comes from 'cp'.
It may seem nitpicky, but such misleading does NOT aid understanding.

(My comment is off-topic, but so is the whole thread.)

James

 

[BartC]

But there is for Windows. He's used those facilities, and he'd like
to port his application to *nix.

Yes, exactly. I'd even gone as far as going through PDcurses under Windows
(a version of ncurses), so that it'd would work painlessly under Linux - as
I thought.

Maybe his application does something
logical when you tap the alt key three times while holding
ctrl-shift-backspace and wiggling the mouse. I'd probably be a poor
customer for that application, since I don't think I'm coordinated
enough to use that UI.

I want to use Ctrl+Home, for example, to get to the top of a document.

PDcurses returns that under Windows (but not Shift+Ctrl+Home, which marks
text from here to the top of the file).

But Ncurses under Linux doesn't recognise *any* shift combinations for keys
like Home!

So a Linux library ported to Windows, works better than it did under Linux!

(And there are also zillions of cars on the roads; why not just take a taxi
instead of buying your own?!)

 

[glen herrmannsfeldt]

(snip)

Not unreasonable questions. I'd say that anything past whatever
specified the program to be executed and the end of the command being
passed to that program, after doing any user specified processing,
would be the "raw" input. Thus you'd not pass the stuff on the other
side of a pipe, for example, or the text from before a command
substitution ($()) was executed.

Now I might quibble out the syntax of some of those, but that's a
relatively minor complaint*. It's not that I object to globbing, it's
that I think it's something I'd like to ask for, and ask for in
specific places (IOW, I'd be happy to say "cl $(*.c)" if I wanted to
compile all C program in the directory). IMO, the automatic globbing
is genuinely useful in a small number of places, in many places being
able to specify several inputs via a wild hard is occasionally handy
but would be a complete non-issue to require explicit specification
(because the single file name case is far more common), and a real
PITA in others (let's just consider ls), to the point of making some
things flat out impossible. The mistake is that catering for the
small number of cases has messed up other stuff, when the small number
of cases could have been better handled by providing those
applications a globthisstring() function.

It works well with most unix commands, partly because they were
designed to work with it.

The unix ls command, for example, gives the files inside the specified
directory, unless -d is specified.

There are a few places where it is less convenient than it could
otherwise be, especially for those previously using other systems.

There is no standard unix command to do the equivalent of the
VMS or MS-DOS RENAME command with wild cards. Consider:

RENAME abc.* def.*

and compare to the result of typing

mv abc.* def.*

in unix.

Another case that fails is the unix dd commmand.

dd if=*.c of=xyz

will fail even if there is only one *.c file in the directory.

Fundamentally, the shell has no idea what in a command might be a
filename, and taking the approach that anything that looks like it
might be a wild-carded filename should be treated as such is, IMO,
rather silly. Something that was hacked in without enough
consideration back in the dark ages sometime, and something were now
stuck with. And has been pointed out in this thread, the way shells
handle edge conditions (like a wildcard specification not matching any
files) varies between shells.

-- glen

 

[Shao Miller]

Am I the only one annoyed that in Linux
cp none*
produces
cp: No match
?? It implies, falsely that the message comes from 'cp'.
It may seem nitpicky, but such misleading does NOT aid understanding.

(My comment is off-topic, but so is the whole thread.)

It does? When I do that, it says:

cp: missing destination file operand after `none*'

When I do 'cp none* .', it says:

cp: cannot stat `none*': No such file or directory

 

[Lew Pitcher]

Now, far afield from C, we come to

On Sunday 13 January 2013 07:10, in comp.lang.c, (e-mail address removed) wrote:
[snip]

I want to use Ctrl+Home, for example, to get to the top of a document.

PDcurses returns that under Windows (but not Shift+Ctrl+Home, which marks
text from here to the top of the file).

But Ncurses under Linux doesn't recognise *any* shift combinations for
keys like Home!

Often, an X "GUI desktop" will reserve some shift combinations for itself.
In KDE 3.5, for instance, <shift><home> is reserved for KDE's "home"
function.

Be mindful of the environment. Curses can only receive keysequences that the
OS (or it's proxys, like X and it's window managers) pass to it. Try
running your curses-based program in a raw terminal, not under X control.

So a Linux library ported to Windows, works better than it did under
Linux!

Not really. Windows does less than Linux does. And PDCurses is /not/ curses;
it is a Curses subset, written for Microsoft DOS applications. Hence, it
works within the confines (limits and abilities) of a DOS environment,
and /not/ within the limits and abilities of a Unixish environment.

FWIW, Curses (on Linux) supports the KEY_SHOME (shifted home) key.


[snip]

 

[88888 Dihedral]

Lew Pitcheræ–¼ 2013å¹´1月14日星期一UTC+8上åˆ12時21分44秒寫é“：

Now, far afield from C, we come to



On Sunday 13 January 2013 07:10, in comp.lang.c, (e-mail address removed) wrote:

[snip]

I want to use Ctrl+Home, for example, to get to the top of a document.

PDcurses returns that under Windows (but not Shift+Ctrl+Home, which marks

text from here to the top of the file).

But Ncurses under Linux doesn't recognise *any* shift combinations for

keys like Home!

Often, an X "GUI desktop" will reserve some shift combinations for itself..

In KDE 3.5, for instance, <shift><home> is reserved for KDE's "home"

function.



Be mindful of the environment. Curses can only receive keysequences that the

OS (or it's proxys, like X and it's window managers) pass to it. Try

running your curses-based program in a raw terminal, not under X control.

So a Linux library ported to Windows, works better than it did under

Linux!

Not really. Windows does less than Linux does. And PDCurses is /not/ curses;

it is a Curses subset, written for Microsoft DOS applications. Hence, it

works within the confines (limits and abilities) of a DOS environment,

and /not/ within the limits and abilities of a Unixish environment.



FWIW, Curses (on Linux) supports the KEY_SHOME (shifted home) key.





[snip]

--

Lew Pitcher

"In Skills, We Trust"

Acctually DOS 3.X to DOS4.X only supported
non-re-entrant IRT and a simple command invoker
that worked in the real memory under 640K but
could be shelled in a primitive way still within
the memory limit.

Anyway, I got my 1024X768X256 color multi-sync
color monitor from Matsushita's Panasoic logo
and VGA card to experiment on the DOS part in
1991-1992 for a budget about USD 1000 at that time.

Anyway I was managed to do quite a few
interesting things at that time without resorting
to an infant linux system to show 256 color images.

 

[Phil Carmody]

BartC wrote:
) I've just discovered that a single command line argument containing
) wildcards, such as *.c, is expanded to a full list of matching files before
) it gets to main().

It gets expanded even before the program is started, by the shell.

) That isn't really what I want (and there could be thousands of matching
) files, which I may not want to deal with in my C program, but pass on to
) something else, or the argument may not be a file specification at all).
)
) Is there any way this behaviour can be changed, without needing to write
) arguments in a special way?

No.

Almost certainly yes, but it depends on the shell being used, as it's a feature of the shell.

E.g. in bash:

$ ls *.ppm
IMG_8013.ppm IMG_8014.ppm IMG_8015.ppm IMG_8016.ppm IMG_8017.ppm IMG_8018.ppm IMG_8021.ppm middle.ppm

$ set -f

$ ls *.ppm
ls: cannot access *.ppm: No such file or directory

Phil

 

[Greg Martin]

I assure you, the Linux console and xterm are more accurate emulations of
the
VT100 than anything you ever saw in Windows (unless you had a Windows
xterm)

This is where you lose me. I'm not interested in emulation of any sort of
terminal. I just want to read keys from my keyboard; how difficult can
it be?

I understand that with standard line input via C's getchar() and so on, the
OS or the library will take care of basic line-editing; that's fine.

But moving just one step beyond that, in order to implement a console-based
editor for example, seems to have been made extraordinarily difficult for
some reason!

The terminal interface is based on streams of characters,
corresponding to
stdin and stdout/stderr. The format of these streams is usually ASCII
or a
superset of ASCII like ISO8859-x or UTF-8. Where in any of those
character
sets do you find "shift+ctrl combos"?

The keyboard handling I want needs two kinds of key presses. Printable
keys,
and control keys. They don't need to share the same code-space. I don't
expect it to work with stdin as I said above, and I don't see the need to
have to encode everything as a serial stream of ASCII codes either.

xterm reports modifiers as part of the escape sequence for control keys,
so
you can distinguish F1 from Ctrl+F1 from Shift+Ctrl+F1

I'm sorry I don't know what xterm is. And I don't really want to know!
Isn't
there just a language or OS function to just tell me what the next key
event
is?!

[n]curses only attempts to organize the common features of the
traditional
terminal types in a coherent way, and raw keyboard mode isn't one of
them.

They must use a different meaning for 'coherent' than is generally
understood! The special key codes returned by ncurses are all over the
place, and capabilities seem to vary wildly between Windows and Debian
for example (the latter ignores most shift combinations).

When your input scheme isn't ASCII or UTF-8, you need a more ambitious
library than curses. Like SDL, or an X11 widget library (Xt+Xaw/Xm, tk,
wxWidgets, gtk, etc.) or raw Xlib.

Help! It sounds so complicated that I may have to forget the whole thing,
and just make my editors etc work with the minimum set of keys that are
certain to be available. (However, the SDL looks intriguing..)

Have a look at the GDK portion of GTK+. It includes some keyboard
handling objects. Actually some time perusing GTK+ might turn up some
other goodies of interest to you.

The approach in UNIX has been very different from that of MS. Software
is often written to take advantage of the OS and the work of other
developers and is done so in a highly modular way. The invention of the
pipe has a lot to do with it. It doesn't mean it's the only way things
are done but culturally people are used to directing the output of one
program to another in a chain, the output of which accomplishes
something not envisioned by the whomever wrote the individual filters.

While I don't agree with everything you'll find in it "The Art of UNIX
Programming" is an interesting read.

 

[osmium]

Lew Pitcher? 2013?1?14????UTC+8??12?21?44???:

Now, far afield from C, we come to



On Sunday 13 January 2013 07:10, in comp.lang.c, (e-mail address removed) wrote:

[snip]

I want to use Ctrl+Home, for example, to get to the top of a
document.

PDcurses returns that under Windows (but not Shift+Ctrl+Home, which
marks

text from here to the top of the file).

But Ncurses under Linux doesn't recognise *any* shift combinations
for

keys like Home!

Often, an X "GUI desktop" will reserve some shift combinations for
itself.

In KDE 3.5, for instance, <shift><home> is reserved for KDE's "home"

function.



Be mindful of the environment. Curses can only receive keysequences
that the

OS (or it's proxys, like X and it's window managers) pass to it. Try

running your curses-based program in a raw terminal, not under X
control.

So a Linux library ported to Windows, works better than it did under

Linux!

Not really. Windows does less than Linux does. And PDCurses is /not/
curses;

it is a Curses subset, written for Microsoft DOS applications.
Hence, it

works within the confines (limits and abilities) of a DOS
environment,

and /not/ within the limits and abilities of a Unixish environment.



FWIW, Curses (on Linux) supports the KEY_SHOME (shifted home) key.





[snip]

--

Lew Pitcher

"In Skills, We Trust"

Acctually DOS 3.X to DOS4.X only supported
non-re-entrant IRT and a simple command invoker
that worked in the real memory under 640K but
could be shelled in a primitive way still within
the memory limit.

Anyway, I got my 1024X768X256 color multi-sync
color monitor from Matsushita's Panasoic logo
and VGA card to experiment on the DOS part in
1991-1992 for a budget about USD 1000 at that time.

Anyway I was managed to do quite a few
interesting things at that time without resorting
to an infant linux system to show 256 color images.

Your Komodo dragon, the world's largest living lizard, is found... in the
lesser Sunda Chain of the Indonesian Archipelago...

 

[Phil Carmody]

No longer a C question, per se, but bash's behavior (at least on
my slackware 14.0 box) is a bit more complicated than suggested above.
echo * echoes a list of all files as stated
echo t*.c echoes test.c because that's the only such file in my /home
echo a*.c echoes a*.c apparently because there are no a*.c files at all
So if there are no matches, it reverts to echoing the string rather
than emitting an error like ls would. Is there a more general rule
behind that behavior?

As always, man bash(1). When there, /nullglob and /shopt.

e.g.:
"""
$ echo *.xxx
*.xxx
$ shopt -s nullglob
$ echo *.xxx

"""

Phil

 

[Tim Rentsch]

[snip] If you say it's just what was typed, a program would need a
complex parser just to work out what it's first argument is! [snip]

^^^^
Oh no! Not you too.... :/

Me too what? The existence of typos in my posts can't be news --
I must have just about the highest typo rate of anyone here!

If you meant to imply that a typo indicates a lack of knowledge,
then I must retort "oh no, not you too?" because I've got very
used to that particular canard over the years!

I'm sorry, what I was trying to say came out wrongly. What I
meant was another person writing a possessive "its" with an
apostrophe. My comment wasn't meant to be directed specifically
at you, or about what the cause might be -- just the result. If
it came across differently, I apologize.

 

[Alan Curry]

Yes, exactly. I'd even gone as far as going through PDcurses under Windows
(a version of ncurses), so that it'd would work painlessly under Linux - as
I thought.

Does any of that stuff work when you telnet or ssh into the Windows box? The
great thing about curses-based applications under unix is that the answer to
that question is "they work exactly the same". Because programs that don't
work remotely are kind of ridiculous in the Internet era.

Anyway, it seems you were fooled by the name "PDcurses". It's not a port of
curses or ncurses. It's an independent clone, and not meant to be an exact
one. The HISTORY file has this to say about the first version (when it was
called "PCcurses"):

There are some parts left out between ncurses and PCcurses. One is the
support for multiple terminals - not very interesting on a PC anyway.
Because we KNOW what terminal we have, there is no need for a termcap or
terminfo library. PCcurses also has some things that neither curses nor
ncurses have. Compared to the original UNIX curses, PCcurses has lots of
extras.

Fancy key combinations would be part of the "lots of extras".

I see that PDcurses is on sourceforge now (no updates lately, but maybe it
doesn't need any) and allegedly runs on Linux, with an X11 backend and an SDL
backend. Give that a try?

So a Linux library ported to Windows, works better than it did under Linux!

If you prioritize things like "recognize Ctrl+Home" over things like "support
multiple terminals" and "work over the network". Those priorities just seem
backwards to any right-thinking unix programmer.

 

[BartC]

Does any of that stuff work when you telnet or ssh into the Windows box?

It's possible I'm not using the right library for what I want to, which is,
IMO, extremely basic input and output for a non-graphic display mode, that
is (in a small way) cross-platform. That is:

o Being able to write text at (row, column) on a screen or console window,
preferably in a choice of primary colours. (Both sets of curses seem just
about capable of that)

o Being able to know what keys have been pressed on my keyboard, including
the various shifts that all computer keyboards have had for decades. I don't
consider Ctrl+Home to be that esoteric. (What key combo do *you* use to get
to the beginning of a file? I bet it involves a shift, ctrl or alt key!)

o And being able to do so without the intermediate library taking over my
machine and/or my program (like SDL, which disables stdout and stderr!)

If you prioritize things like "recognize Ctrl+Home" over things like
"support
multiple terminals" and "work over the network". Those priorities just
seem
backwards to any right-thinking unix programmer.

Imagine a computer without a network attached, but with a keyboard and basic
character display. You would surely expect those peripherals to work,
without having half their capabilities unavailable because the protocols for
controlling them via a network can't accommodate them.

It seems that with Unix, I have to pretend that even the simplest peripheral
I want to access is at the end of a link, via an interface not updated since
the 1970s!

 

[Greg Martin]

It's possible I'm not using the right library for what I want to, which is,
IMO, extremely basic input and output for a non-graphic display mode, that
is (in a small way) cross-platform. That is:

o Being able to write text at (row, column) on a screen or console window,
preferably in a choice of primary colours. (Both sets of curses seem just
about capable of that)

o Being able to know what keys have been pressed on my keyboard, including
the various shifts that all computer keyboards have had for decades. I
don't
consider Ctrl+Home to be that esoteric. (What key combo do *you* use to get
to the beginning of a file? I bet it involves a shift, ctrl or alt key!)

o And being able to do so without the intermediate library taking over my
machine and/or my program (like SDL, which disables stdout and stderr!)


Imagine a computer without a network attached, but with a keyboard and
basic
character display. You would surely expect those peripherals to work,
without having half their capabilities unavailable because the protocols
for
controlling them via a network can't accommodate them.

It seems that with Unix, I have to pretend that even the simplest
peripheral
I want to access is at the end of a link, via an interface not updated
since
the 1970s!

Again, I'll point you to GTK+. I don't know how much has been ported to
cygwin but it has libvte for terminal emulation.

http://developer.gnome.org/vte/0.26/

 

[Ben Bacarisse]

It's possible I'm not using the right library for what I want to, which is,
IMO, extremely basic input and output for a non-graphic display mode, that
is (in a small way) cross-platform. That is:

o Being able to write text at (row, column) on a screen or console window,
preferably in a choice of primary colours. (Both sets of curses seem just
about capable of that)

Not if the display is monochrome. Now I know you know this, but the
point is a general one. A library like curses hides this form you.
Some displays allow fine-grained control of the brightness of individual
characters and soon some 3D display may well allow a z-position. When a
feature becomes common place, libraries like ncurses will offer support
for them, but since the purpose of ncurses is portability it is
inherently conservative about such things.

o Being able to know what keys have been pressed on my keyboard, including
the various shifts that all computer keyboards have had for decades. I don't
consider Ctrl+Home to be that esoteric.

It may not be esoteric, but it is not universal. If you want a program
to work using common terminal types you have to accept that Ctrl+Home
can't be used.

There are ways to get round this:

(a) Use your own X window. XLib lets you know a huge amount about what
keys are being pressed and exactly when. My editor, being X aware, lets
me bind Ctrl+Alt+Super+Home (to pick an extreme example) but when I run
the editor in a terminal emulation I have to accept that this won't work
because the terminal being emulated has no way to say "Ctrl+Alt+Super+
Home was pressed and released".

(b) Go a little bit beyond what ncurses gives you and accept a loss of
flexibility. You can write a small function to read and return and
extended set of key combinations but you must then tell your users that
the software needs to run in, say, an xterm window. (I choose xterm
because it generate unique escape sequences for all sorts of
combinations like Ctrl+Home, Shift+Ctrl+Home and so on.)

(What key combo do *you* use to get
to the beginning of a file? I bet it involves a shift, ctrl or alt
key!)

(Home three times: the first goes to start of line, the second to the top
of the page and the third to start of the file. Multi key presses like
this are so fast that it's probably quicker the Ctrl+Home.)

o And being able to do so without the intermediate library taking over my
machine and/or my program (like SDL, which disables stdout and stderr!)


Imagine a computer without a network attached, but with a keyboard and basic
character display. You would surely expect those peripherals to work,
without having half their capabilities unavailable because the protocols for
controlling them via a network can't accommodate them.

I'd expect them to work (and of course they do) but you can't insist
that the work the way you want them to or that you are used to. My hard
drive works, but user programs can only access it via an very complex
and high-level abstraction provided by the OS. You are kicking against
the abstraction that *nix systems use for non-graphical terminals. All
you can do is take a deep breath and move on.

It seems that with Unix, I have to pretend that even the simplest peripheral
I want to access is at the end of a link, via an interface not updated since
the 1970s!

Obviously it has been updated, but the model is from the 1970s. It
works surprisingly well and has enough advantages that it's not going to
go away anytime soon. It's not uncommon to see old terminals still
plugged in to servers for monitoring purposes and so on.

It wouldn't be hard to provide a general method to do what you want.
All that would be need is some patches to a good terminal emulator like
xterm so that it reports (as escape sequences) raw key presses and
releases. An extended curses library could then provide access to this
virtual hardware at all sorts of levels, from actual events like "left
control down" to "Ctrl+Home pressed and released".

But I suspect this would not take off because the benefits are small
compared to work required, and programs that have any sort of
portability limitation can be viewed with suspicion. For example, with
no patching at all, you could bundle your editor with xterm (because it
does report Ctrl+Home) but the fact that it won't run in my preferred
terminal program would put me off.

 

[Roberto Waltman]

... to delve deeper into the system to get even basic shift+ctrl combos working?

Since nobody mentioned it, (or if somebody did, I missed it, sorry),
look at the source code for the emacs editor, both the X11 and "noX"
versions.

If Esc-Meta-Alt-Control-Shift can do it, so can you in your code.

 

[Alan Curry]

It's possible I'm not using the right library for what I want to, which is,
IMO, extremely basic input and output for a non-graphic display mode, that
is (in a small way) cross-platform. That is:

o Being able to write text at (row, column) on a screen or console window,
preferably in a choice of primary colours. (Both sets of curses seem just
about capable of that)

Cursor positioning and character attributes: yes, those are core
features of curses from the beginning, since they were supported by all
terminals. (Originally the attributes were just bold/underline/inverse/blink,
then colors showed up.)

o Being able to know what keys have been pressed on my keyboard, including
the various shifts that all computer keyboards have had for decades. I don't
consider Ctrl+Home to be that esoteric. (What key combo do *you* use to get
to the beginning of a file? I bet it involves a shift, ctrl or alt key!)

In the editor "vim", the command for "move to beginning of file" is gg.
No shifting necessary! The classic vi command is 1G (i.e. Goto line 1),
which does involve a shift key to generate the G, but the editor doesn't
*know* that you used the shift key. Typing "1g" with caps-lock on would
do the same thing. The editor can't tell the difference. It only knows
that it received an uppercase G (ASCII code 71).

Have you ever used a unix text editor before deciding you needed to make
a new one?

o And being able to do so without the intermediate library taking over my
machine and/or my program (like SDL, which disables stdout and stderr!)

The one time I tried to run an SDL program it locked up my console
pretty thorougly. I'm not a fan...

Imagine a computer without a network attached, but with a keyboard and basic
character display. You would surely expect those peripherals to work,
without having half their capabilities unavailable because the protocols for
controlling them via a network can't accommodate them.

Imagine also that you've designed a multi-user operating system, and
that you can't take seriously a computer with no network and only a
single keyboard and screen attached. Would you take the time to design
an API to allow convenient access to all of the hardware capabilities,
then hope that enough programs get written or rewritten with the new API
to make it worthwhile? Or just make it emulate a serial terminal so you
can run the thousands of programs you've already got?

Unix vendors during the critical transition period chose the easy option
(the second one). They never created any API for DOS-like text-mode
applications that assume direct access to a local keyboard and monitor.
And it's too late now. The ASCII + ECMA-48 terminal paradigm has its
disadvantages but it's available everywhere, good enough most of the
time, the old users are used to it, and the new users faint instantly at
the sight of text mode so they won't appreciate any improvements to it.

It seems that with Unix, I have to pretend that even the simplest peripheral
I want to access is at the end of a link, via an interface not updated since
the 1970s!

Yes, you've got it!

That or go full GUI. Or keep trying to find something in between those two
options, and suffer from the flakiness of the lesser-used libraries.