In The Beginning Was The Command Line, Updated 416
Unqualified code-monkey Garote submits his annotated version of Neal Stephenson's In The Beginning Was The Command Line, updated to discuss UI design theory and fill in some of the gaps from the last five years. (And yes, he has been granted permission from Neal to do this.) There's plenty more to cover of course: Will the command-line last only as long as the keyboard? How will desktop search technology change our workflow? What about the 3D interface? Scroll to any random paragraph in the essay and you'll find something worth expounding on. What's ahead for the next five years?
Hopeful (Score:4, Interesting)
Hopefully, some higher power will pick an OSS desktop, create some interface and application standards and we can all start dumping Windows. Until then, my Linux migration ends at the point where I have to pick gnome or KDE (or even something else).
Which one should I pick and why?
Future ? (Score:3, Interesting)
It'll still be flat (2D) and people should now realize that what counts is the input.
For years, we only had one focus at a time and this should change, thus allowing drastical changes (imagine if several networkedusers have a focus on an app at the same time... impossible ? who remembers the Acorn "Spheres of chaos" where 4 users could play on the same machine at the same time ?).
So, I'd go for a more practical approach to a 2D interface (I was thinking of some itnerface that would ban both scrollbars and overlapping windows by magnifying the active zone of each focussed elements while reducing the others thus making these still visible, ergo invokable)...
Monad (Score:5, Interesting)
IMHO, it's one of the strangest and most surprising moves in Longhorn.
Real computing (Score:4, Interesting)
When it comes to computing, I started out at the command line. True computing, to me, IS the command line, and I gained the most understanding of computers from it. I prefer to use Linux that way (I don't load a GUI). "Windows is a good terminal" is how I think Richie put it, and although the GUI is here and necessary, real computing will always be from the command line. I will admit Lynx never replaced a GUI web browser for me, but someone who really knows the command line (and therefore the OS) can run circles around the mousey admins....
Re:As long as the keyboard? (Score:3, Interesting)
I can't imagine ever having speech recognition being good enough for a programmer, it would be too slow to have to say "cout less than less than quote capitalised Hello comma world less than less than quote semi colon", and it would make the workplace an awful noisy place
But what about the non-invasive "thinking caps" featured recently in a story? Maybe one day we'll be able to simply "see" the word or line and it will be entered...
Re:As long as the keyboard? (Score:3, Interesting)
And why would that be the case considering how long time it takes to be proficient in typing? Surely, it is possible that an alternative text entry interface would emerge in the future.
For example Dasher [cam.ac.uk] is pretty cool, and there are other (in fact numerous) alternative interfaces. See for example Masui's on-line bibliography [pitecan.com].
Eventually (Score:3, Interesting)
Re:As long as the keyboard? (Score:3, Interesting)
Or think them?
Or look at something and have the brainwaves converted into words applicable to that which you're looking at (or have bound to that image).
The command line will only be around as long as there is a keyboard... and the keyboard won't live forever.
Re:Not NS's best work... (Score:2, Interesting)
No, you obviously don't know what we are talking about.
Press CTRL-R and some letters: the history is searched backwards for that command. Press it again and go back for other occurrences.
doskey... pah!
And we are NOT talking of "addons". Most of the pipe filters are part of the basic binary apps.
Sure, if you are on a Digital Unix 4.0 machine you are pretty much stranded with the oldish and poor userland utilities, but on modern linux CLIs all the things I'm talking about are there FOR SURE.
Installing a *nix app in my book means "windows has a featureless cli".
Oh, and please, try this on windows:
(yes, I know about the backticks, but I have no time to search how to post those in slashdot)
Re:pick anything (Score:3, Interesting)
I was (and still am) a windows power user who was going up the very steep learning curve of learning Linux some 5/6 years ago. I could do "some" stuff with it, but it wasn't until my main PC died and I was left with my Linux laptop for a couple of weeks that I all of a sudden Just-Got-It tm
These days all operating systems are all pretty much the same as far as I am concerned, XP is a great desktop, Linux is a great server, Sun is a great number cruncher and I still miss CP/M
Command shells could stand improvement (Score:5, Interesting)
What's peculiar to me is how crusty and stale most command line environments have become. Most UNIX users swear by bash, which isn't even as nice as 4NT for Windows. Feels like there's a lot of room for improvement here. For example, how about capturing all of the output per command, then quickly allowing you to scroll through a list of previous commands and jump to its output? Or getting away from overly static command line windows and instead having something like a simple text editor, where you can move around in a "document" and press Enter at any time, with the output always appearing below it (some language interpreters work like this). And shell scripting languages are irrelevant these days, so a shell doesn't need to be bulked up with such commands. Just use Perl or Python (or whatever) for that sort of thing.
Note again, I'm not trashing the command line. I'd simply like to see it move forward.
Be careful about using metaphores (Score:3, Interesting)
When comparing a industrial strength drill (hole-hawg:unix/linux) to a normal drill (consumer-drill:windows/mac) the commenter writes:
What's more powerful, a hole-hawg, or a five-speed consumer drill with large grips, a safety shut-off, and a built-in level? The hole-hawg, obviously. But which would you rather use to drill, say, five hundred chandelier mounts in a ballroom?
I have to go with the tool that has a good chance of drilling 500 mounts. I don't trust fancy consumer drills to survive drilling many large deep holes.
Which, I think, also applies to unix/linux. I don't get all misty-eyed and sniffly at the thought of using a shell and good ol' CHUI tools. Nope. I use them because they consistantly get the job done quicker and easier than other tools.
The problem is that a lot of these nifty tools are scary, in meatspace and in cyberspace. They also require some training before use -- a steep learning curve. Take a bolt extractor (looks like a very corsely threaded thich screw with a square end for the wrench). Hand one to the average person and they won't know what the hell its for. But with a little knowledge and another simple tool (a good drill and a bit for metal) its rather useful to take out a broken bolt. What about a cutting torch? Screw up, and you'll be seeing grandma and Elvis. Learn to use it correctly and you'll be able to remove a drum from a vehicle with rusted out brake hardware, or to cut through thick chunks of iron.
Are these tools a little macho? Perhaps some of them (cutting metal with fire is damn fun). But is that why these tools are in use? No, these tools are used because they get the job done.
I have money in the bank, and I spend enough time in front of a monitor to be able to justify the purchase of software tools if they were able to fulfill a need that OS tools could not (and a certain proprietary OS is an excellent software tool for running proprietary games).
This commenter reminds me of someone who got into OSS because OSS was "cool".
Imagine someone who decides that he'll learn vim because hackers use vi (or emacs). He looks at a cheat sheet, figures out what i, a, hjkl, and :wq does, and is content at being a "hacker" for the next six months. Afterwords, he discovers some nice commercial IDE and, sick of the lack of features he finds in vim, decides to go with the commercial IDE. After all, he knows that vim can't lookup man pages for functions, jump to a function declaration, change its indentation style, edit multiple files, integrate with compiler errors, or a host of many other things that the commercial IDE can do. He sits back convinced that those OS lusers are fooling themselves, the same way he fooled himself.
The ultimate UI (Score:2, Interesting)
I've been trying to get my wife to use Linux (Score:1, Interesting)
I use Debian for everything except Quicken, and sometimes I even get that to work via Wine, depending on the effects of the most recent apt dist-upgrade.
My wife uses the computer solely for email and simple games like solitaire. She went for three years without ever trying Debian, even at my urging. Recently, I changed the background images for the login manager and her KDE desktop, and now she thinks Debian is the coolest thing in the world.
Re:I thought it was something else... (Score:1, Interesting)
Debugging meant finding the bug, removing it, and cleaning the ichor off of the circuit board.
Also why hasn't anyone mentioned the mile long punched paper tape rolls, like the ones my dad used to feed into vietnam era helicoptor simulators. You didn't want that tape to break!
LOL
Hey, someone else uses zsh too! (Score:3, Interesting)
I first tried it coz Mac OS X doesn't come with ksh, where my previous experience was, but it did come with zsh which was supposed to be like it.
But since then, I've come to love some of its unique features. In particular, the recursive filename completion is just wonderful -- I use it all the time, and it makes things so much easier. All right, you can probably use the 'find' command to do many of the same things, but having it right there in the globbing is so much neater and easier.
Trivial example: to remove a file from the current directory, I might use
To remove it from any subfolders too, I just use But it's much more powerful than that: it's trivial to select files by type, size, permissions, age, &c &c, and there are exclusions and umpteen other possibilities. In fact, I haven't used the find command once since getting the hang of zsh!And zsh has many other great features, too, including most things I recall from bash, ksh, &c. And it's free and open source, and supplied with Mac OS X... I'm really surprised it's not more popular, coz IMO it deserves to be.
Re:Still flawed, since there is no reference to OS (Score:2, Interesting)
Microsoft was probably still about two or three years away from having a releasable version of Cairo, when they decided to divert resources to produce Windows 95.
Re:Still flawed, since there is no reference to OS (Score:3, Interesting)
OS/2 scared Microsoft enough to drop plans for a much bigger rewrite and instead release Windows 95, and it was based on their fear of losing a chunk of the home market AND the big chunk of the business market that Windows 3.x had finally acquired them.
Microsoft's activities vis-a-vis the IBM PC Company show pretty conclusively that they viewed OS/2 (especially v3) as a threat.
Re:Command shells could stand improvement (Score:2, Interesting)
You mention the concept of "something like a simple text editor, where you can move around in a "document" and press Enter at any time, with the output always appearing below it"
I first wrote an editor like this in 1985, using Forth on a C64. In 1988 I implemented it using APL on a mainframe, later using CPM/VM (???), xedit and REXX. I implemented it using Java and an invented language called Dork (which might appear on Sourceforge eventually), and when I migrated to Linux I had a shot at getting it working by piping Dork stdout into bash.
All of these environments not only allowed you to "press Enter" at any point to execute the text, but also allowed you to organise the "document" as a heirarchical tree of pages with arbitrary hyperlinking between each page (again, just "press Enter").
This is without a doubt the most powerful way of working that I have ever used, and I miss it greatly in my day to day work. Remember, that these environments are first and formost text editors, so you mix text (documentation, comments etc), commands and output as you see fit. You only differentiate when you want to execute something. You don't need to swap to another mode, or type
Bash history is NOT the same thing. History is strictly sequential and chronological, an edited document is organised by task or subject matter, hence the commands you find there are related to that task or subject.
All the flack you got was from people who simply did not get what you were talking about. Maybe also because you rubbished one of the most powerful tools in the linux/unix/gnu world - the shell.
Also, you got a comment like "just go hack the source code yourself". Well, easier said than done. I recently had a look at xterm code to do what I thought would be a simple change. No way! The code even had comments like "If you think you understand this code, you don't" Even the maintainers weren't completely sure what was going on in the code! I wouldn't be surprised that bash is just as difficult - just look at the man page to see how complex it is! Sometimes good ideas come from people who are not capable of implementing them.
I realise that emacs could do this, but I have not got into emacs enough to make it happen. I got introduced to vi quite early and find emacs really annoying to use, so haven't yet tackled what is yet another learning curve (linux has so-o-o-o many of them!) to get emacs to work in the way you describe. So I keep looking at different linux-based technologies (emacs, tk, mozilla, curses, parrot..) thinking "could I use this to make [your/my] idea work - and how much work is it really?". Even considered the gwm window manager - that may still be the key. Anyhow
What I really want to say is this:
I have tried this idea in real life to do real work, and it made my work a whole lot easier. It IS a good idea, but it is a whole different conceptual model from the line-by-line mode that CLI shells normally use. Therefore most people will probably not understand what is being described, or why it is such a powerful concept.