BSD General Commands

Then , in essence, it's a mini-OS. Working like DOS, no GUI.

Maybe not like a mini-OS, but it is similar to the DOS command prompt. Microsoft took parts of Unix, and parts of Digital Equipment Corporation RT operating system, and parts from CP/M operating system.

The opposite of what Microsoft does, correct?

The opposite of just about every interactive operating system at the time.

As for a hobby, it's old and long gone railroads in this area...

My Grandfather was an engineer. Scared the ... out of me when he took me into the cab and blew the horn. I was like 4 or 5 years old at the time. And my uncle lived across the street from the local round house and switching yard with the turntable. And there was both steam and diesel running the tracks at the time (mostly diesel).

The 'ls' command is what you are looking for and it does have a gazillion options.

man ls

ls -1 # digit 1

ls -l # lowercase L

The default 'ls' command sort would be just as you expected (straight alphabetical) with Test1 follwed by Test10, Test11, Test12, then Test2, Test20, Test21, Test22, etc...

I do not have sufficient experience with DOS to know how Microsoft would have done it, but I suspect it would be the same as the 'ls' command.

In truth, since I mostly have my Finder folders set to sort based on either Modified date or Added date, I have not noticed the difference in the sort ordering.

And I actually spend most of my time working in a terminal emulator ssh'ed (remotely logged) into a Linux system doing file system development for some unnamed Fortune 100 company.

(Yes I'm old enough to remember Pres. Nixon! LOL)

And I got to see President Kennedy stand up in a convertible on the NY Turnpike to wave at some Nuns standing on an overpass. There are a lot of us senior citizens hanging around these forums.

And herein lies the problems for beginners, how the <expletive deleted> is a beginner supposed to know this?

I would ask the same question. How would you know to find a .pdf file?

However, in defense of 'man' pages, they are for commands which are not the center of Apple's focus. Apple is focused on the GUI.

The Terminal interface is there because every Unix system has a terminal emulator interface to the Unix command line, and it is assumed that if you want to play in that space you have an idea about what to do or are interested enough to research it. For the most part Apple could care less about the command line. It is not what sells their products. iPhones, iPads, Apple Watches, Apple TV's do not even have a command line, even though they all have a some of the same operating system bits as macOS. Apple is not focused on the command line.

And I have observed over the years, that users with a GUI interface are mostly happy to not read a manual, and just do enough pointing and clicking to accomplish what want, even if it is not the most efficient approach.

So writing extensive manuals (even if shipped as PDF files) would not be very cost effective, and Apple has shown the world, from the first GUI based Mac, that you can make a boat load of money and not spend time writing extensive documentation for each release.

And that has created a 3rd party industry of book writers providing the manuals.

And I read that 8 feet of VAX/VMS manuals (more than once) and I can tell you that they left a lot to be desired, because what you think is important, is not always the tech writers opinion, and sometimes getting details out of the developer writing the software is next to impossible, and many times the information is presented in a dry manor, and no one bothers to connect the dots between feature X and feature Y to do something amazing. That is left as an exercise to the user.

At least the 3rd party book writing industry is motivated to make their books interesting so they can keep selling them.

Which railroad, if I may ask?

Remember I was 4 or 5 years old.

All I can tell you is that the switch yard was in Bangor, Pennsylvania, across the street from the post office. Bangor, PA is on the eastern side of Pennsylvania about half way up the state. The switch yard is gone, and today there are building where the tracks used to be.

How may zeros in gazillion, BTW? LOL

https://en.wikipedia.org/wiki/Indefinite_and_fictitious_numbers

Smart folders are saved searches. Finder also provides saved searches.

Might want to look at using Mojave as a guest of a virtual machine on Catalina, as that’ll get you on newer software and a path toward Big Sur, while providing access to your older apps. Staying on old gets more expensive, until most folks get dragged forward, and getting dragged forward across the intermediate releases gets painful, the more of those there are.

Windows descended from DEC VAX/VMS by way of DEC MICA, FWIW.

Windows libraries and DLL, um, hades have been longstanding issues, though they’ve headed toward .NET as their portable framework. VAX/VMS had earlier versions of those same issues, and other redirection methods.

seL4, Geode, DragonflyBSD, and many other operating systems are all available.

All sorts of history around, and all sorts of new work too. And it’s always changing. Arm processor work with macOS apps now, too.

Vertical bar is the token for the shell pipe, yes, and bash parsing will usually need the tokens with one or more spaces on both sides of the token. One detail that confused me early in was the token placement in the “newer” if syntax.

Where bash uses a stream of characters in the pipe—which is what TCP also provides, a stream—PowerShell schleps around objects.

Yandex is one of the choices for searching. The Yandex image search works quite well.

And yes, Apple tweaks each new release, a phenomenon undoubtedly familiar to any long-time user.

Haven’t checked on Yandex-related settings in a while. It was there (Safari Default Search Engine changed to Yandex - Apple Community) but does seem to have fallen out of the search engine selection list in Safari on the Mojave box just checked.

For a data stream on Unix and as with a literal stream, there are no delimiters, no data segmentation. It’s all one long string. The recipient gets to figure out where the interesting data within the stream begins and ends, what the string encoding might be, etc. The writer might write discrete hunks of data, but those hunks aren’t preserved for the recipient.

Particularly with TCP, the number of write reuests might not match the number of read requests. The reader loops and re-assembles the arriving contents into the app’s work buffer. The writer might write a single one-hundred-byte I/O write operation out, and the reader some combination of reads totaling 100. Or totaling more than one hundred, if the writer has slung subsequent I/O writes into the stream.

UDP both being datagrams and being intentionally unreliable works rather differently than TCP, here.

The app programming requirements around streams is part of why some folks will choose and use MQTT or ilk for networking, rather than using TCP directly, etc.

Windows references are largely lost on me. While the clients and servers in use around here are an eclectic mix, I’ve not particularly worked with nor managed Microsoft versions past Windows XP.

The thing about a Unix stream is that Unix does not impose rules about what the data looks like. So you can store anything in a file, you can send anything through a pipe, etc... The Unix operating system does not require you application to fit is round peg into the Unix square hole.

So while a stream may sound like total chaos, it makes perfect sense to the creator and the receiver of the bits, and anyone else that wants to play in the same sandbox as the creator and receiver for those bits. The handful of operating system developers are not imposing their rules on your data based on their limited to non-existent understanding of your data. They leave that up to the people creating the data.

As someone that started with 80 column punched cards, and worked with operating system that imposed on-disk formatting rules that in many cases was just an extension of an 80 column punched card, I came to appreciate the Unix data stream and the freedom it gave me when moving data from one medium to another (disk vs magtape) and between systems, ESPECIALLY when they were different manufactures and different operating systems (I spent a lot of time doing format conversions that had nothing to do with the data).

I’ve long wondered if a whole lot of Unix code has latent timing dependencies, assuming that local I/O always presented the app with the amount of file data requested and when requested, but that the file system data—being a stream—could conceivably operate much closer to how TCP behaves. But I’d expect wholesale app and OS implosion, if the file system acquired enough latency.

But yes, stream I/O and file streams are useful.

I do prefer object to either stream or record data, though.

Lots of reading here, around bash and zsh and the other shells, on data manipulation, character encodings, algorithms, tools and frameworks and APIs (MQTT, SQLite, etc), all that and more is awaiting...