4 ms·
Bash is a shell. Learn the shell, and you "learn" bash.
by deafpolygon 3y ago
Bash is a shell. Learn the shell, and you "learn" bash.
- DonHopkins 3y agoAt the risk of being accused of bash bashing, I'll throw down that bash is a weak ineffective shell. A "shell" can and should be so much more than all bash has to offer. The much earlier more powerful ITS (Incompatible Timesharing System) shell DDT (whose job name was HACTRN) had an integrated PDP-10 machine language debugger / assembler / disassembler, so you could interactively or batch "script" and patch DDT and even other jobs in full blown PDP-10 assembly language. Why invent yet another half assed "scripting" language that no other jobs in the system are using, when you can use the same fully powerful machine language that every job in the system is using? And if you need to do anything complicated, there's always LISP! DDT's syntax was even more obscure than bash (and only a bit less obscure than TECO), but it was much more powerful and elegant, unleashing the full undiluted power of the PDP-10 at your fingertips. https://github.com/PDP-10/its/blob/master/doc/_info_/ddtord.1462 https://github.com/PDP-10/its/blob/master/doc/_info_/ddtord.... You could also write DDT commands in text files like your login file, i.e. assembling a few lines of code to print the prompt by making a system call to get the time and format it as text. You could examine and deposit code and data, load and change symbols, set breakpoints, in your own and even other user's running jobs (processes)! You could disconnect without logging out (accidentally or not) and all your jobs would stay around until you logged back in, at which time you could reattach your job tree and continue what you were doing, all without running something like "screen" -- that crucial feature was just built in and always worked. You could also pass ownership of jobs (like a running ZORK game or LISP interpreter or FOOBAR feeper) back and forth between users to share, like passing a joint. ;) https://news.ycombinator.com/item?id=22840639 https://news.ycombinator.com/item?id=22840639 >It helped that ITS had no security whatsoever! But it had some very obscure commands, like $$^R (literally: two escapes followed by a control-R). >There was an obscure symbol that went with it called "DPSTOK" ("DePoSiT OK", presumably) that, if you set it to -1, allowed you to type $$^R to mess with other people's jobs, dynamically patch their code, etc. (The DDT top level shell had a built-in assembler/debugger, and anyone could read anybody else's job's memory, but you needed to use $$^R to enable writing). http://www.poppyfields.net/filks/00117.html http://www.poppyfields.net/filks/00117.html The HACTRN Original song: The Raven Original artist: Edgar Allan Poe Filk author: Guy L. Steele Jr. Intro: Notes for those not familar with the terms in this poem -- see below [...] DDT ("dee dee tee") HACTRN ("hack-tran") = top level debugging and job controlling procedure, capable of controlling up to eight simultaneous jobs (which may themselves be DDTs!) and performing other miscellaneous functions. HACTRN specifically denotes a DDT at the top of a job tree, while DDT is the more general term. The two terms refer to the same job in the poem, and are thus treated as synonymous. Note that DDT requires its subjobs to have unique names for obvious reasons; hence the concern over seven jobs all named FOO.
- deafpolygon 3y ago> And if you need to do anything complicated, there's always LISP! Are you an Emacser?
- hello_computer 3y agoSeveral of these sound like anti-features. Others are OS issues and have no bearing on the shell (i.e. ownership hot-swap). The ones that are useful have already been solved by other programs (screen, gdb, et al). What is the advantage of having it all packed inside the same executable?