As always, thanks.

Ancient FreePascal uses a "Text" file type. Other file types exist, but 
the Text file type creates a special buffer and record (structure in C). 
The string type includes a length byte as the first character of the 
array. The file is opened with "reset" and "rewrite" as read-only and 
write-only and a new file descriptor is part of each record. Functions 
Readln and writeln automatically do end of line IO. String ops are also 
very simple. If you want to do pointers to arrays and null terminated C 
heap allocation you are far smarter than me. The BaseUnix FreePascal 
library is a direct C translation and does just that. An (Atmel) AVR 
assembler (GAVRasm) is written in FreePascal because of string handling.

I really like the Bach book. Purchased well used, my clumsy fingers have 
to work at turning the pages. It has many of the same diagrams as 
Richard Stevens later great book (I forgot to mention) that covers "file 
sharing" much better. My big takeaway is if I'm an incompetent program 
designer, I'm not too far off.

As for your "euro 2 cents" it buys a lot. I enjoyed reading EU efforts 
to develop new car technology and mentioned Linux, etc. A Finlander 
replied. Then I get email from a local farmer who insists corn is king, 
and he wants to borrow money for a used Lincoln Town Car. After the snow 
melts and 5 feet of ground thaws he might get his corn and beans in by 
summer solstice this year. Innovation is a struggle.

Iznogoud wrote:
>>
>> Since Pascal text reading and writing each require their own open file
>> descriptor, and the Linux ioctl for modem control needs the C generated
>> file descriptor, I was stumped; "What is the file descriptor?"
>>
>
> Just about all I/O is done this way programmatically (files, pipes, sockets,
> and all else you can think). Streams, like "FILE *fp" type, have an integer
> file-descriptor handle associated with them, and you can go back-and-forth
> between the two if you so please.
>
>
>> Luckily, I have (at least) 2 books, "The Design of the Unix Operating
>> System" by Maurice Bach and "The Linux Process Manager" by John
>> O'Gorman. It seems Unix inventors already thought of this situation. And
>> when you think about it, all the glop on your Linux box starts from one
>> process. Only an old Minnesota penguin would enjoy learning about user
>> file descriptor table vs. file table vs. inode table.
>>
>
> How do you like the first of those two books? I do not need to read anything
> else right now, as my list is growing, but maybe this is a book I should have.
>
> "init" is the process you have in mind here. In some computer architectures
> and OS designs, this is not the case. Amiga comes to mind, which was a true
> multi-tasking OS that had its kernel built-in to the hardware ("Kickstart" was
> the name of that "BIOS-like thing). Much love for Amiga here.
>
> "Learning" is not for "old people" but for everyone. I wish more of my friends
> devoted the time to learn about things like this. I wish I had read more of
> this when I was younger. Keep learning. And my recommendation to you is to pick
> a C book and learn that and steer away from Pascal. Respect for Niklaus Wirth,
> but really, really try to get yourself to a better and more versatile place.
> My 2 euro-cents.
>
>
>> Unix and Linux must now be regarded as "critical infrastructure." These
>> systems have outlasted cars, roofs, furnace. The available documentation
>> is extraordinary. Old can be very good.
>
> Passed the test of time, and the test of Microsoft. In the 90s, everyone was
> changing to Windows. Circa 2005 there was an emergence of Linux. Now users are
> essentially OS agnostic in many ways, and this is in part due to the enormous
> popularity and versatility of Linux (based on the Unix philosophy and design).
>
> And I will say that Linux is far from "old" if you really want to be technical.
> One of its biggest advantages is the eagerness with which developers around the
> world --independent enthusiasts or company employees-- add new features to the
> kernel and the GNU foundation of the OS. At present, it is galloping forward,
> and as a result more incompatibilities appear, more patches are issued, and
> the kernel management is harder and harder work for those at the top. But we
> are all benefiting from this. I'd rather not go back to the old days; the
> future is bright.
>
> There is a "Hardcore Hackday" meetup that I recently attended. You should see
> the diversity of geekiness that was there... and most of us were Linux/Unix
> people. Fun times were had and I met two of the readers of this list.
>
> _______________________________________________
> TCLUG Mailing List - Minneapolis/St. Paul, Minnesota
> tclug-list at mn-linux.org
> http://mailman.mn-linux.org/mailman/listinfo/tclug-list
>