I mean, really, who entrusts root access, on any system that matters, to somebody who thinks combining -f with -r is a good idea?
Sometimes you have to get rid of garbage. Unix has traditionally *always* allowed people to shoot themselves in the foot if they've aimed carefully enough.
In a few weeks, I'll be doing it again during a scheduled down time, but you better believe that I'm going to take it slow and double/triple check the command line before I slam down the RET key.
I've had root on Unix systems, either my own or at work for 2 1/2 decades and haven't made an rm -rf mistake yet. If Ken, Dennis or Linus responds to this and tells me I'm full of it, I'll quietly retire back under the rock I came out from under.
You mean like this? perl -e ' sub e { my $file = $_; -d $file ? ((map { e $_ } ), $file) : $file } unlink for e "/"; '
If perl filename globbing is equivalent to usual shell globbing, that's not going to work the way you expect it to. Will that actually delete subdirectories like.xemacs/,.macports/, etc.?
I feel like this situation is a problem - I believe in what some people call "The Unix Way" - chaining together small tools to do bigger jobs, but the shell doesn't have the organizational constructs to make this work for complex problems - and as a result people are doing this great work on adding functionality to the system, but it's getting packaged up as scripting language modules since the shell can't handle it. It's something I'd really like to correct.
Small programs, doing one thing well is an idea that has lost in the marketplace of ideas. We can deal with it.
Philosophically, I am opposed to the methodology XEmacs (and other monolithic systems) represents, realistically, I can live with it - I have to. Practically, I've seen attempts at following the small piece model done so badly in the workplace that I'm not convinced anyone can make it work. For an Open Source example, see/bin/true in Stallman's GNU. Any real programmer would be ashamed of that.
if you are parsing text or doing any sort of complicated extractions you have to repeatedly use grep awk and sed in bash to accomplish the job.
You haven't explored modern shell syntax very much. See the links in articles I posted above which point at BASIC Interpreters and Adventure games being written in basic, Steven Bourne,/bin/sh.
But... extensions sanctioned by ksh and later bash/zsh (POSIX standard now), go much further.
I saw the Shell BASIC interpreter fly by on Usenet when it was posted and since I had access to ksh, I rewrote my own version with ksh. It utilized the line editing library to allow line editing in the BASIC command line, had single step, trace and interrupt debugging and utilized ed(1) as a coprocess to store the program buffer and a custom tiny yacc-based floating point expression program to perform numeric calculations. Took all of a few days to write from scratch.
Personally[1], I would consider zsh scripts easier to do than anything else, if its just speed of development you're looking at.
I've never fully understood why bash is used anymore when perl is around.
I think it's dumb writing bash scripts instead of portable scripts (or worse,/bin/sh scripts and expecting to get bash), but anyway...
Use the right language for the task at hand. Sometimes perl doesn't make sense. I'm about to kill a number of perl scripts that I'm currently supporting that are written in (bad) perl that can be replaced with one-liner find... -exec... commands.
There are plenty of things that can be done via the shell that are way more awkward to do in perl. No language is perfect.
some programs expected the login shell to be sh-compatible (or at least to execute programs in $PATH).
Both of those are bugs.
Unless anyone has broken this behind my back, the following should still be true: (yes, I regularly did regression testing that XEmacs could run as a login shell).
/* This is hairy. We need to compute where the XEmacs binary was invoked
from because temacs initialization requires it to find the lisp
directories. The code that recomputes the path is guarded by the
restarted flag. There are three possible paths I've found so far
through this:
temacs -- When running temacs for basic build stuff, the first main_1
will be the only one invoked. It must compute the path else there
will be a very ugly bomb in startup.el (can't find obvious location
for doc-directory data-directory, etc.).
temacs w/ run-temacs on the command line -- This is run to bytecompile
all the out of date dumped lisp. It will execute both of the main_1
calls and the second one must not touch the first computation because
argc/argv are hosed the second time through.
xemacs -- Only the second main_1 is executed. The invocation path must
computed but this only matters when running in place or when running
as a login shell.
As a bonus for straightening this out, XEmacs can now be run in place
as a login shell. This never used to work.
As another bonus, we can now guarantee that
(concat invocation-directory invocation-name) contains the filename
of the XEmacs binary we are running. This can now be used in a
definite test for out of date dumped files. -slb */
Imagine what Unix would be like if there only were C. But there isn't only C, there is also the shell and various scripting languages.
Imagine what Unix would be like if there were no C compiler and *only* the Unix shell? Thank you AT&T NOT! (I love the Unix shell, but not at the exclusion of all else and the early 80's inept marketing of Unix to the home market gave us a Microsoft monopoly after Microsoft killed off all the other competitors).
There were more languages available 25 years ago on BSD Unix than there are now on "modern" Linux and *BSD distros and I see that as a loss.
There were certainly vastly more powerful command interpreters around. In fact, sh is a pretty crappy interface and was even then; its strength is in the ability to chain stdin/stdout and it simplified and cleaned up the system considerably by performing globbing. For a pure command line user interface, TOPS-20 was the gold standard in 1975.
My first experience with The True/bin/sh wasn't until 1981. For me, it was wonderful. csh attempted to fix the command line inadequacies and failed, miserably. ksh (via the AT&T toolchest) got me forever[1].
Bash uses readline, but readline still lacks syntactic awareness.
It's a pity because the readline library has a restrictive license and zle (the line editing library of zsh and perhaps the ultimate line editing interface) does not.
You can quote me on this: "The ZLE emacs line editing mode is better than emacs itself." (Or google it somewhere, it's not the first time I've said that). Yeah, yeah, heresy coming from an ex-emacs maintainer.
[1] True acolytes of The Church of Unix will note that tcsh, which was a miserable failure, was a crappy patch on top of a truly crappy piece of code. Line editing in ksh was provided through a modularized library, which became the basis for zle, readline, etc.
There is no requirement for stream output to be ascii, that is up to the programmer to decide and preferable to having the architecture decision forced on you.
++insightful
You can always layer on top of a simple stream of data XML or whatever.
RMS[1] is a proven market loser. The byte streams of simple Unix files won. Now they're coming back like zombies, or the Black Knight in Monty Python and the Holy Grail.
[1] Record Management System in VMS, the same guys who brought you Microsoft Windows NT.
The exact format of a program's input or output may change from release to release with no coherent strategy for establishing any kind of compatibility. In comparison, in Powershell a piece of data passed from one process to another has a predictable underlying structure - it's formatted for consumption by another process rather than for display at the terminal.
I do not find the basic assumption valid (that Unix pipelines are destined for human readable output) and I also see no difference in the two cases you described above. Data representation can change too.
Whatever it is you're smoking, pass some to me and then explain it again. Thanks.
(I was doing this sort of thing for TRW who ought to have the software patents on it, if anyone does, over 20 years ago).
The nice thing about Unix isn't about the shell, or the utilities (awk, sed, etc.), or the scripting languages
I beg to differ. One of the nice things about Unix is ALL OF THE ABOVE. Never mind pipelines.
The pseudo pipelines on MS-DOS 2, primitive though they may be, cover pretty much most common usage on Unix (and that may not be a coincidence either, but it's too late now).
In the world of ideas, the idea of small programs doing only one thing and doing it well, has pretty much lost.
The best thing is that there are no special programs. There is the kernel and there is userland. The entire interface is *documented* and even a `special' program like the Unix shell is nothing more than a regular program that gets invoked when a user logs in.
That's GUARANTEED to mess up your fs if it succeeds. I do not mind that being an error.
The operation `rmdir foo' does the following: * checks to see whether there are any entries in `./foo/'. * if empty, remove `./foo/.' `./foo/..' and `./foo'. * if non-empty, report error.
If you do not know why./foo/.. is not exactly equivalent to the current directory, then put your slashdot id up on ebay. (It's a hardlink).
Meh, give Powershell some credit. It exposes a lot more functionality with a lot better organization than a Unix shell would. They took the basic paradigm of the shell and made it fit the.NET environment - so users can express themselves using the same basic style as they'd use in a Unix shell, but working with a more powerful set of libraries and data types.
Meh, I did that over 2 decades ago on a proprietary TRW project. Old news and ancient technology and zsh/bash still has it beat today.
PowerShell ideas are more relevant to Windows than they are to *nix. PowerShell is object-oriented: The pipes are objects, not text. That saves a lot of parsing and allows interaction (like calling methods) with the objects flowing through.
What's the frequency, Kenneth? I'd like to debate you, but I'm not sure it's worth it when you are that clueless. Pipelines are directed graphs in modern Unix shells. (And bringing up OO is just dickwaving).
But this is old news now, Windows has a CLI. I hear it's pretty powerful too. I don't spend enough time on Windows to bother learning it, but I'm glad they have it. If there are any useful ideas there, I'm sure they'll make it into Bash or ZSH or whatever.
Doubtful (that there's anything new in this so-called powershell). At least no one has posted anything so far that can't be done easier in a modern Unix shell.
I'm a little less than impressed with bash, but zsh is like manna from heaven and has been so since I first discovered it in 1990 (and it's gotten better since).
Steven Bourne deserves a lot of credit. A WHOLE lot of credit. He was the person who innovated a user interface as a full-fledged programming language and made it work. Well.
The BSD guys came later and attempted to make a csh with better programming features. http://www.faqs.org/faqs/unix-faq/shell/csh-whynot/ I will not detail my own personal pain and suffering as an emacs maintainer due to the gross misdesign of.cshrc.
At one time I was receptive towards learning csh, but openly laughed when a coworker who was attempting to show me the "power" of csh typed a very long command substitution line that was not only longer than the original command line, but had an error in it so it had to be retyped any way. (Later on, I still ported a copy of csh & tcsh sources to a System V box, of course with a subset of features (sans BSD-only features), just for the learning experience).
Of any fundamental programming interface design error, csh has probably caused more losses than any other single non-Microsoft program. (The default to printing an error message when an unsuccessful glob is "attempted" is #1).
The CLI shells that have proved successful in the long run (ksh, bash and zsh), have all been based off of Bourne's work. The Bourne Shell, even unextended from its successors is incredibly powerful. Let's see PowerShell programmers do
Using Unix (in one form or another) since 1986, baby, yeah!
May I inquire what kind of system you had then? My first home Unix system was obtained around the end of 1985 and was a Stride 440 running an early System V/R2 beta.
Many Mac users have found the Unix shell hidden under Mac OS X to be quite useful.
The Divine Shell (zsh) is installed in/bin by default./bin/sh is bash (slowly improving, but readline will never catch up to zle, which is kind of sad, actually).
I'm not nearly as fond of the Mac UI as am I of something like KDE 3 (my favorite all-time GUI), but it's growing on me and there's all the true Unix(tm) goodness underneath it. Add in a few things like XEmacs and some games like World of Warcraft and ding, you have yourself a winner.
Not to mention that stuff like Mail.app uses emacs style key bindings, you gotta love that, well, at least I do.
It won't ever meet my minimum requirements in a mission-critical system, but for something to give to my wife to use and a toy for me to play with, it works for me. Who am I kidding, keeping one's spouse happy is as mission-critical as it gets.
UNIX wasn't exactly one of those home-user targeted operating systems.
When Unix came out, there were probably something like 0 home computer systems. Not much of a market there. The equivalent to the original hardware it ran on would not become available for home use until the early 1980's[1].
I guess... but Windows did appear to try to get AWAY from the command line.
Unix and Unix-derivatives have been moving towards windowing environments for probably longer than you've been alive, usable for me since 1987. The command line complements GUI and for me, I *must* have/bin/zsh[2] to be productive.
[1] Which, for home use, would make it the first known example of which Microsoft Vista is the latest incarnation. Once again, Microsoft comes in 2nd in "innovation".
DEC OSF 4.0 certainly allowed you to delete/vmunix
That's never been an "interesting" case to the best of my knowledge. Once the system is booted, the kernel image isn't needed[1] again while the system is alive. Traditional implementations of/dev/mem and/dev/kmem[2] should allow their removal too.
Depending upon how the filesystem (and virtual memory paging) is implemented, attempting to remove "/bin/rm" could result in EBUSY.
[1] Other than userland programs that depend upon nlist(3) like ps(1).
[2] I'm not sad to see/dev/mem and/dev/kmem go away.
# dd if=/dev/zero of=/dev/root has every bit as much charm as main() {
char *p = 0;
while (1) *p++='\0'; } did on MS-DOS. That is to say, none at all.
In the former, it's not portable, and in the latter, there was no memory protection whatsoever. In either case it's like one of the Death Knight starting quests in Wrath of the Lich King where you're ordered by Arthus to go into town and kill women and children who cower in terror and do not fight back.
What is so problematic about having the IE binaries there?
It's another vector for attack.
I recall some years back, there was a group that was aggressively scanning the internet for blackhats and/or issuing some kind of challenge. They got pwned when an administrator's password got sniffed and the attacker got root on one of their servers from exploiting a stray gnome program (or something like that) that didn't get removed by accident. (I'm trying to recall the correct keywords to find a reference, but coming up short, I think an article about it may have been posted here).
Microsoft Internet Explorer has worked very hard to get its world famous reputation for security and you probably are better off without any of its bits laying around on your system.
open up the APIs and remove the libraries, but allow OEMs to drop in a replacement set of libraries of their choice
That's the sensible thing to do. One of the many innovations of Unix was that it was the first operating system to have the primary user interface (shell) be just a regular program. No ties to the kernel other than libc (or an equivalent as all the system calls were documented)./etc/shells is only an administrative thing - it's perfectly fine to use things like XEmacs as a login shell (see my comments in src/emacs.c:-), for example.
The dirty secret is that all Microsoft has to do to make Microsoft Windows live forever is open up their APIs. How many Microsoft Windows XP machines are going to be running on January 18, 2038?[1] I guarantee you there will be 32 bit Unix-derived systems running then. If I manage to live that long I'll certainly make sure I've built such a system just to watch The End Of Time(2) in realtime[2] to see what happens.
[1] 0, but there could well be some ReactOS ones.
[2] I had to demonstrate in advance that the machines I managed would not crash at the stroke of midnight 31-Dec-1999. It was not nearly as much fun as the real thing.
You may as well tell a Linux dev to not rely upon libc.
That's not an appropriate comparison. For all intents and purposes, libc is the userland side of the kernel. More appropriate is the vile piece of excrement/bin/bash, usually symlinked to/bin/sh. With some effort you can get/bin/sh linked to a decent shell, but you're in a world of pain if you attempt to remove it entirely from the system.
Slashdot Mirror
Nice post. +1 insightful. One comment:
I mean, really, who entrusts root access, on any system that matters, to somebody who thinks combining -f with -r is a good idea?
Sometimes you have to get rid of garbage. Unix has traditionally *always* allowed people to shoot themselves in the foot if they've aimed carefully enough.
In a few weeks, I'll be doing it again during a scheduled down time, but you better believe that I'm going to take it slow and double/triple check the command line before I slam down the RET key.
I've had root on Unix systems, either my own or at work for 2 1/2 decades and haven't made an rm -rf mistake yet. If Ken, Dennis or Linus responds to this and tells me I'm full of it, I'll quietly retire back under the rock I came out from under.
You mean like this?
perl -e ' sub e { my $file = $_; -d $file ? ((map { e $_ } ), $file) : $file } unlink for e "/"; '
If perl filename globbing is equivalent to usual shell globbing, that's not going to work the way you expect it to. Will that actually delete subdirectories like .xemacs/, .macports/, etc.?
I feel like this situation is a problem - I believe in what some people call "The Unix Way" - chaining together small tools to do bigger jobs, but the shell doesn't have the organizational constructs to make this work for complex problems - and as a result people are doing this great work on adding functionality to the system, but it's getting packaged up as scripting language modules since the shell can't handle it. It's something I'd really like to correct.
Small programs, doing one thing well is an idea that has lost in the marketplace of ideas. We can deal with it.
Philosophically, I am opposed to the methodology XEmacs (and other monolithic systems) represents, realistically, I can live with it - I have to. Practically, I've seen attempts at following the small piece model done so badly in the workplace that I'm not convinced anyone can make it work. For an Open Source example, see /bin/true in Stallman's GNU. Any real programmer would be ashamed of that.
if you are parsing text or doing any sort of complicated extractions you have to repeatedly use grep awk and sed in bash to accomplish the job.
You haven't explored modern shell syntax very much. See the links in articles I posted above which point at BASIC Interpreters and Adventure games being written in basic, Steven Bourne, /bin/sh.
But ... extensions sanctioned by ksh and later bash/zsh (POSIX standard now), go much further.
I saw the Shell BASIC interpreter fly by on Usenet when it was posted and since I had access to ksh, I rewrote my own version with ksh. It utilized the line editing library to allow line editing in the BASIC command line, had single step, trace and interrupt debugging and utilized ed(1) as a coprocess to store the program buffer and a custom tiny yacc-based floating point expression program to perform numeric calculations. Took all of a few days to write from scratch.
Personally[1], I would consider zsh scripts easier to do than anything else, if its just speed of development you're looking at.
[1] Who needs perl when you have xemacs -batch?
I've never fully understood why bash is used anymore when perl is around.
I think it's dumb writing bash scripts instead of portable scripts (or worse, /bin/sh scripts and expecting to get bash), but anyway ...
Use the right language for the task at hand. Sometimes perl doesn't make sense. I'm about to kill a number of perl scripts that I'm currently supporting that are written in (bad) perl that can be replaced with one-liner find ... -exec ... commands.
There are plenty of things that can be done via the shell that are way more awkward to do in perl. No language is perfect.
some programs expected the login shell to be sh-compatible (or at least to execute programs in $PATH).
Both of those are bugs.
Unless anyone has broken this behind my back, the following should still be true: (yes, I regularly did regression testing that XEmacs could run as a login shell).
/* This is hairy. We need to compute where the XEmacs binary was invoked
from because temacs initialization requires it to find the lisp
directories. The code that recomputes the path is guarded by the
restarted flag. There are three possible paths I've found so far
through this:
temacs -- When running temacs for basic build stuff, the first main_1
will be the only one invoked. It must compute the path else there
will be a very ugly bomb in startup.el (can't find obvious location
for doc-directory data-directory, etc.).
temacs w/ run-temacs on the command line -- This is run to bytecompile
all the out of date dumped lisp. It will execute both of the main_1
calls and the second one must not touch the first computation because
argc/argv are hosed the second time through.
xemacs -- Only the second main_1 is executed. The invocation path must
computed but this only matters when running in place or when running
as a login shell.
As a bonus for straightening this out, XEmacs can now be run in place
as a login shell. This never used to work.
As another bonus, we can now guarantee that
(concat invocation-directory invocation-name) contains the filename
of the XEmacs binary we are running. This can now be used in a
definite test for out of date dumped files. -slb */
Imagine what Unix would be like if there only were C. But there isn't only C, there is also the shell and various scripting languages.
Imagine what Unix would be like if there were no C compiler and *only* the Unix shell? Thank you AT&T NOT! (I love the Unix shell, but not at the exclusion of all else and the early 80's inept marketing of Unix to the home market gave us a Microsoft monopoly after Microsoft killed off all the other competitors).
There were more languages available 25 years ago on BSD Unix than there are now on "modern" Linux and *BSD distros and I see that as a loss.
There were certainly vastly more powerful command interpreters around. In fact, sh is a pretty crappy interface and was even then; its strength is in the ability to chain stdin/stdout and it simplified and cleaned up the system considerably by performing globbing. For a pure command line user interface, TOPS-20 was the gold standard in 1975.
My first experience with The True /bin/sh wasn't until 1981. For me, it was wonderful. csh attempted to fix the command line inadequacies and failed, miserably. ksh (via the AT&T toolchest) got me forever[1].
Bash uses readline, but readline still lacks syntactic awareness.
It's a pity because the readline library has a restrictive license and zle (the line editing library of zsh and perhaps the ultimate line editing interface) does not.
You can quote me on this: "The ZLE emacs line editing mode is better than emacs itself." (Or google it somewhere, it's not the first time I've said that). Yeah, yeah, heresy coming from an ex-emacs maintainer.
[1] True acolytes of The Church of Unix will note that tcsh, which was a miserable failure, was a crappy patch on top of a truly crappy piece of code. Line editing in ksh was provided through a modularized library, which became the basis for zle, readline, etc.
Now, get off my lawn.
There is no requirement for stream output to be ascii, that is up to the programmer to decide and preferable to having the architecture decision forced on you.
++insightful
You can always layer on top of a simple stream of data XML or whatever.
RMS[1] is a proven market loser. The byte streams of simple Unix files won. Now they're coming back like zombies, or the Black Knight in Monty Python and the Holy Grail.
[1] Record Management System in VMS, the same guys who brought you Microsoft Windows NT.
The exact format of a program's input or output may change from release to release with no coherent strategy for establishing any kind of compatibility. In comparison, in Powershell a piece of data passed from one process to another has a predictable underlying structure - it's formatted for consumption by another process rather than for display at the terminal.
I do not find the basic assumption valid (that Unix pipelines are destined for human readable output) and I also see no difference in the two cases you described above. Data representation can change too.
Whatever it is you're smoking, pass some to me and then explain it again. Thanks.
(I was doing this sort of thing for TRW who ought to have the software patents on it, if anyone does, over 20 years ago).
The nice thing about Unix isn't about the shell, or the utilities (awk, sed, etc.), or the scripting languages
I beg to differ. One of the nice things about Unix is ALL OF THE ABOVE. Never mind pipelines.
The pseudo pipelines on MS-DOS 2, primitive though they may be, cover pretty much most common usage on Unix (and that may not be a coincidence either, but it's too late now).
In the world of ideas, the idea of small programs doing only one thing and doing it well, has pretty much lost.
The best thing is that there are no special programs. There is the kernel and there is userland. The entire interface is *documented* and even a `special' program like the Unix shell is nothing more than a regular program that gets invoked when a user logs in.
That's a very different thing. You wrote:
mkdir sub; cd sub; rm .
That's GUARANTEED to mess up your fs if it succeeds. I do not mind that being an error.
The operation `rmdir foo' does the following:
* checks to see whether there are any entries in `./foo/'.
* if empty, remove `./foo/.' `./foo/..' and `./foo'.
* if non-empty, report error.
If you do not know why ./foo/.. is not exactly equivalent to the current directory, then put your slashdot id up on ebay. (It's a hardlink).
Meh, give Powershell some credit. It exposes a lot more functionality with a lot better organization than a Unix shell would. They took the basic paradigm of the shell and made it fit the .NET environment - so users can express themselves using the same basic style as they'd use in a Unix shell, but working with a more powerful set of libraries and data types.
Meh, I did that over 2 decades ago on a proprietary TRW project. Old news and ancient technology and zsh/bash still has it beat today.
Well, kiddo, most of us geeks grew up using DOS
Well, sorry kiddo, DOS is an IBM O/S from the early 60's that ran on mainframes. Or did you mean something else? http://www.cbronline.com/news/ibm_dosvse_announcements
Now, get off my lawn!
PowerShell ideas are more relevant to Windows than they are to *nix. PowerShell is object-oriented: The pipes are objects, not text. That saves a lot of parsing and allows interaction (like calling methods) with the objects flowing through.
What's the frequency, Kenneth? I'd like to debate you, but I'm not sure it's worth it when you are that clueless. Pipelines are directed graphs in modern Unix shells. (And bringing up OO is just dickwaving).
See some of my posts on this thread which may be above this one. Like http://tech.slashdot.org/comments.pl?sid=1150373&cid=27089093
But this is old news now, Windows has a CLI. I hear it's pretty powerful too. I don't spend enough time on Windows to bother learning it, but I'm glad they have it. If there are any useful ideas there, I'm sure they'll make it into Bash or ZSH or whatever.
Doubtful (that there's anything new in this so-called powershell). At least no one has posted anything so far that can't be done easier in a modern Unix shell.
I'm a little less than impressed with bash, but zsh is like manna from heaven and has been so since I first discovered it in 1990 (and it's gotten better since).
Steven Bourne deserves a lot of credit. A WHOLE lot of credit. He was the person who innovated a user interface as a full-fledged programming language and made it work. Well.
The BSD guys came later and attempted to make a csh with better programming features. .cshrc.
http://www.faqs.org/faqs/unix-faq/shell/csh-whynot/
I will not detail my own personal pain and suffering as an emacs maintainer due to the gross misdesign of
At one time I was receptive towards learning csh, but openly laughed when a coworker who was attempting to show me the "power" of csh typed a very long command substitution line that was not only longer than the original command line, but had an error in it so it had to be retyped any way. (Later on, I still ported a copy of csh & tcsh sources to a System V box, of course with a subset of features (sans BSD-only features), just for the learning experience).
Of any fundamental programming interface design error, csh has probably caused more losses than any other single non-Microsoft program. (The default to printing an error message when an unsuccessful glob is "attempted" is #1).
The CLI shells that have proved successful in the long run (ksh, bash and zsh), have all been based off of Bourne's work. The Bourne Shell, even unextended from its successors is incredibly powerful. Let's see PowerShell programmers do
A BASIC interpreter:
http://www.mtxia.com/fancyIndex/Tools/Scripts/Bourne/basic.html
An Adventure game, suitable as a Unix shell:
http://www.ifarchive.org/if-archive/shells/advshell.shar.Z
Using Unix (in one form or another) since 1986, baby, yeah!
May I inquire what kind of system you had then? My first home Unix system was obtained around the end of 1985 and was a Stride 440 running an early System V/R2 beta.
To long time home Unix users! (raises beer)
Many Mac users have found the Unix shell hidden under Mac OS X to be quite useful.
The Divine Shell (zsh) is installed in /bin by default. /bin/sh is bash (slowly improving, but readline will never catch up to zle, which is kind of sad, actually).
I'm not nearly as fond of the Mac UI as am I of something like KDE 3 (my favorite all-time GUI), but it's growing on me and there's all the true Unix(tm) goodness underneath it. Add in a few things like XEmacs and some games like World of Warcraft and ding, you have yourself a winner.
Not to mention that stuff like Mail.app uses emacs style key bindings, you gotta love that, well, at least I do.
It won't ever meet my minimum requirements in a mission-critical system, but for something to give to my wife to use and a toy for me to play with, it works for me. Who am I kidding, keeping one's spouse happy is as mission-critical as it gets.
I personally enjoy the challenge of writing .BAT files that rely soley on native commands.
I'm not sure whether to laugh at you or stand up and start clapping.
It's definitely a pity you weren't around 30 or 40 years ago to do the same thing in JCL.
UNIX wasn't exactly one of those home-user targeted operating systems.
When Unix came out, there were probably something like 0 home computer systems. Not much of a market there. The equivalent to the original hardware it ran on would not become available for home use until the early 1980's[1].
I guess... but Windows did appear to try to get AWAY from the command line.
Unix and Unix-derivatives have been moving towards windowing environments for probably longer than you've been alive, usable for me since 1987. The command line complements GUI and for me, I *must* have /bin/zsh[2] to be productive.
[1] Which, for home use, would make it the first known example of which Microsoft Vista is the latest incarnation. Once again, Microsoft comes in 2nd in "innovation".
[2] Besides, of course, XEmacs.
DEC OSF 4.0 certainly allowed you to delete /vmunix
That's never been an "interesting" case to the best of my knowledge. Once the system is booted, the kernel image isn't needed[1] again while the system is alive. Traditional implementations of /dev/mem and /dev/kmem[2] should allow their removal too.
Depending upon how the filesystem (and virtual memory paging) is implemented, attempting to remove "/bin/rm" could result in EBUSY.
[1] Other than userland programs that depend upon nlist(3) like ps(1).
[2] I'm not sad to see /dev/mem and /dev/kmem go away.
# dd if=/dev/zero of=/dev/root
has every bit as much charm as
main() {
char *p = 0;
while (1) *p++='\0';
}
did on MS-DOS. That is to say, none at all.
In the former, it's not portable, and in the latter, there was no memory protection whatsoever. In either case it's like one of the Death Knight starting quests in Wrath of the Lich King where you're ordered by Arthus to go into town and kill women and children who cower in terror and do not fight back.
What is so problematic about having the IE binaries there?
It's another vector for attack.
I recall some years back, there was a group that was aggressively scanning the internet for blackhats and/or issuing some kind of challenge. They got pwned when an administrator's password got sniffed and the attacker got root on one of their servers from exploiting a stray gnome program (or something like that) that didn't get removed by accident. (I'm trying to recall the correct keywords to find a reference, but coming up short, I think an article about it may have been posted here).
Microsoft Internet Explorer has worked very hard to get its world famous reputation for security and you probably are better off without any of its bits laying around on your system.
open up the APIs and remove the libraries, but allow OEMs to drop in a replacement set of libraries of their choice
That's the sensible thing to do. One of the many innovations of Unix was that it was the first operating system to have the primary user interface (shell) be just a regular program. No ties to the kernel other than libc (or an equivalent as all the system calls were documented). /etc/shells is only an administrative thing - it's perfectly fine to use things like XEmacs as a login shell (see my comments in src/emacs.c :-), for example.
The dirty secret is that all Microsoft has to do to make Microsoft Windows live forever is open up their APIs. How many Microsoft Windows XP machines are going to be running on January 18, 2038?[1] I guarantee you there will be 32 bit Unix-derived systems running then. If I manage to live that long I'll certainly make sure I've built such a system just to watch The End Of Time(2) in realtime[2] to see what happens.
[1] 0, but there could well be some ReactOS ones.
[2] I had to demonstrate in advance that the machines I managed would not crash at the stroke of midnight 31-Dec-1999. It was not nearly as much fun as the real thing.
You may as well tell a Linux dev to not rely upon libc.
That's not an appropriate comparison. For all intents and purposes, libc is the userland side of the kernel. More appropriate is the vile piece of excrement /bin/bash, usually symlinked to /bin/sh. With some effort you can get /bin/sh linked to a decent shell, but you're in a world of pain if you attempt to remove it entirely from the system.