Bash first came out in 1989, but the typical shell of the time was sh, and it ran on Unix systems with more memory, storage, and CPU power than the typical PC. Thus it's no surprise that the sh family started with more features, while COMMAND which cmd evolved from was extremely minimalistic. DOS 1.0's COMMAND.COM was just slightly more than 3 kilobytes and didn't have conditional nor goto statements:
Even if the *nix machine was no bigger than a PC (e.g. - Xenix on '286; BSD on a PDP-11), it could still swap out processes, vs sharing a single real memory space.
But as you said, this allowed (at least the illusion, on some machines) more total memory to work with.
In the 1980's a 80286 would have been toward the high end of x86 systems. The 80386 started shipping in bulk in 1986 and the Compaq DeskPro 386 and IBM PS/2 Model 80 were well north of $5000 in 1987 and the "prosumer" PS/2 was the Model 60 with a 80286 when the line was released.
Even in the late 1980's 8088 based systems were pretty typical and why IBM included the PS/2 25 and 30 in its initial product line.
I remember using (sharing!) an XT (8088? 8086???) at work in 1985. One good thing about the 386 in 1986 was that it made the price of 286 (AT/clone) systems come down. I almost never saw an XT after 1986. We started seeing quite a few more clones (Compaq, etc) about that time, as well.
Which is of course a big tangent off of "why/whence command.com & .BAT files" :-)
OS/2 and Windows were a big deal in virtualizing memory use in PC land, with widespread Linux use still "a few years" in the future. (and effective adoption of NextStep even further out)
I think the 80386SX was also a factor in lower 80286 prices after the 386DX came out. Those systems were really popular.
When I bought the Amiga 500 in 1988, 8088 Turbo machines were still the entry level clone system. My vague recollection of the consumer and small business market was that that obtained for a couple of more years.
bash came out in 1989. The Bourne shell it's backwards compatible with is from 1977. But both were designed to run on Unix on multi-user multi-process machines. DOS batch language was designed to run on a single-user single-process machine. There's a reason they used to make a distinction between "minicomputers" and "microcomputers".
> DOS batch language was designed to run on a single-user single-process machine.
This. My preferred explanation for the difference between Unix and Windows for a long time has been "Unix assumes a lot of people are doing different things on one computer, all at the same time. Windows was designed with the mental model of a calculator."
I apologize for writing in a manner that would mislead someone into believing that I claimed that self modifying code was a need for anyone, let alone systems programmers. It's all Turning complete, even if that completeness comes complete with a tarpit.
To a first approximation, I'd expect that 1980's Unix programmers would generally be working in environments more accepting of restarting a batch process when there was an error in the code, i.e. significantly less likely to hold a clerical or secretarial "TCP report" job in a regular commercial office. Though that split has become less likely, it's still pretty uncommon for a computer user with little control of their work environment and deadlines to be using *nix rather than Windows.
In the Savings and Loan recession I had one of those jobs with unpaid overtime and an employer who was comfortable abusing it. I'd start a batch print job and go home. When I came back next morning picking up the paper off the floor was pure pleasure relative to baby-sitting the machines until midnight or more.
http://www.os2museum.com/wp/dos/dos-1-0-and-1-1/dos-1-0-dir/
http://www.os2museum.com/wp/dos/dos-1-0-and-1-1/