The "loop and a half"

[Chris Angelico]

On Sat, Oct 7, 2017 at 5:51 AM, bartc <bc at freeuk.com> wrote:
> On 06/10/2017 18:42, Chris Angelico wrote:
>>
>> On Sat, Oct 7, 2017 at 4:13 AM, bartc <bc at freeuk.com> wrote:
>
>
>>> So what's the excuse for an unresponsive text display in 2017?
>>
>>
>> Got it. You assume that a system is a coherent computer with its
>> peripherals, rather than being a networked collection of computers,
>> all of them controlled from your laptop in response to a panicked
>> email saying the web site is down. Your terminal exists on your
>> laptop. The programs are being run on any of a number of your servers,
>> possibly several of them concurrently. How do you handle that?
>>
>>>> What text editor do you use there?
>>>
>>>
>>> That depends; are we still in the 1970s?
>>
>>
>> Nope. We're in 2017, where the "system" is often a networked
>> collection of computers.
>
>
> Still no excuse. We were talking about the need to use a crude keyboard
> interface to serially create a file of data a line at a time rather than
> using a proper application for it (such as a text editor).
>
> So which bit do you have access to locally? The keyboard presumably. And the
> display has to be local unless you it's either got a 50' screen or you use
> binoculars. Are you saying the bit in the middle is remote and that is what
> is playing up?
>
> This is exactly the situation from the 1970s that I thought we'd long left
> behind! There really is no excuse for not having the minimum amount of local
> processing power available to be able to enter and review a few dozen lines
> of text without needing to involve a temperamental network.
>
> If you're stuck, whip out a tablet computer or smartphone (they should still
> function without connectivity) and use a preloaded text editor. Or just
> compose and then save an email. Even the simplest should be more
> sophisticated than just blindly entering text on a Linux terminal screen.

Save an email and then what? You need to make a change to something on
a remote server. Maybe your hosts file is borked. Maybe the mail
server configuration is slightly off, resulting in delayed delivery.
Maybe your bindfile has an outdated record in it so half your users
are getting timeouts. Whatever it is, it's almost certainly going to
be managed by a text file in /etc, so you need to edit that file.

How do you edit a file on a remote computer? How do you compare three
instances of that file on different computers to see if one of them is
different?

>>> (And since I mainly use my own languages, actually getting hold of
>>> 'stdin',
>>> 'stdout' and 'stderr' is not trivial. Creating actual named files is much
>>> easier.)
>>
>>
>> More blub happening right there. You start out by assuming that the
>> standard streams are unimportant, therefore you think that providing
>> them is pointless. It's self-perpetuating.
>
>
> They were a creation of either C, Unix, or some combination. Certainly I had
> very little to with any of that for decades. I can't remember that it ever
> stopped me doing anything I needed to do.

That's Blub. You've never used it, so you don't understand its value,
so you scorn it.

> My own programs worked like this (showing original '#' symbol I used);
>
>  print     "One"       # to console (also using print #0)
>  print #f, "Two"       # to file handle f
>  print #s, "Three"     # append to string s
>  print #w, "Four"      # to window or control w
>  print #b, "Five"      # to image b

I'm not sure what printing to a window or image would mean, or how
it's useful, but sure. In Python, you could do the same by making
those things into file-like objects.

> What would I want with stderr?!

That's where you print error messages. It is, in fact, the standard
place to print error messages. That's what it's for. If you're running
a program interactively, stderr goes to the console. If you're running
it interactively with output redirected, stderr still goes to the
console. If you run it detached as a system service, stderr goes to
the system logger. (At least, it should; it does with a lot of service
managers.) If you run it from a web application framework, stderr goes
into the web server's log. Etcetera. The program doesn't need to know
or care - it just writes text to stderr.

>> It's 2017. You should understand at least a bit about the internet and
>> how to use it.
>
> I can use it but can't fix it when it goes wrong.

Can you use it from a program, though? Not just working in a web
browser, mail client, news client, etc - can your applications
establish socket connections, listen for incoming connections, etc?

>> I don't know if you're an idiot or a troll. Using TCP/IP networking is
>> pretty simple (at least if you're using a real language - your own toy
>> languages might have made it unnecessarily hard, for all I know),
>> hardly "over-complex" by comparison to RS-232 programming.
>
>
> So how do you use it from Python - without using an existing Python library?
> Or is it only simple when someone else has made it idiot-proof?

The only "existing Python library" you need is the Python stdlib,
which is effectively part of the language. Basic socket services are
right there in the 'socket' module, and there are various higher-level
protocols provided by their own modules.

>>> I just don't work that way. The OS is there to launch applications, or to
>>> provide a basic API for common services such as a file system. I don't
>>> need
>>> its complicated shells.
>>
>>
>> Blub rears its head again.
>
> How so? I said I have little need for most of what an OS does, in my
> development work, which is perfectly true. Perhaps you haven't noticed that
> many are using sophisticated IDEs now rather than fiddling about with
> command lines. (Mine is not sophisticated, but still better than a command
> line.)

Some are. Many aren't. In fact, the basic terminal has many advantages
over purely GUI systems, including that you can scroll back and see
exactly what happened previously. I generally recommend my students to
use a sophisticated text editor, and then a separate terminal (or, as
I tend to do, *many* separate terminals) to run commands in.

>> At what point will you acknowledge that there are things you do not
>> understand that are actually useful?
>
>
> I can understand that people who use Unix and Linux arrange their world so
> that all these things are apparently indispensable.
>
> What you're trying to tell me is that because Unix provides such a tightly
> knit system system of utilities, stdin, stdout, files, pipes and very
> specific ways of using the keyword (which seems to consist of avoiding
> actually using it for entering data as much a possible; just using the
> logical idea of it), then every other text entry system in the world, in
> whichever OS or application, must follow exactly the same model. Because the
> Unix one is so great.
>
> Needless to say, I disagree.

Yeah. It's called an "ecosystem". And it's called "consistency".
They're good things.

ChrisA