- the X windowing system
- Way too big, half of any Linux distribution is X. Plan9's windowing system rio is about 280kilobytes. The source is 7684 lines of code, including the .h files and the makefile.
- symbolic links
- they were a hack -- the root of Unix thought it owned the file system, including even the imported parts. The Plan9 NameSpace is yours, you, the user, put everything where you want it.
- super-user
- Superuser is a target for crackers and for the script kiddies alike - su confers a power which ignores every bit of security built into the local file system. The wide variety of superusers allowed each of them to inflict their style guidelines on the structure of the file system... Now where did that @#!$ superuser put gcc or perl or ...
- vi, emacs, ...
- Try acme or sam. Sam uses StructuralRegularExpressions.
- find
- The unix find is a SwissArmyKnife. In PlanNine, the TreeWalking is done by du -- a unix find . -print is in PlanNine: du -a|awk '{print $2}'
- objects
- BellLabs didn't need them since the complexity is back under control.
- shell command line history
- roll your own: fn history {grep '^term%' /mnt/wsys/text|sed -e 's/^term%//'} term% is the prompt. Sure looks a lot like Unix. The history is the function of the windowing system. Instead of saying term% I should use some quoted form of cat /env/prompt
- cp -r
- Recursive copy isn't built into the cp command in PlanNine. Imagine how many separate Unix commands have the TreeWalking built into them... RefactorMercilessly. Instead, this shell script, dircp refactors that functionality for the cp command into two invocations of tar:
#!/bin/rc
switch ($#*) {
case 2 @{ cd $1 && tar c . } | @{ cd $2 && tar x }
case * echo usage: dircp from to >[1=2]
}
For solutions to some of the above, see: http://plan9.bell-labs.com/wiki/plan9/UNIX_to_Plan_9_command_translation/index.html There are apparently a few typing intensive alternatives for the commands find and cp -r, etc.
I would imagine that that is a shell issue, not a plan9 issue. I expect that bash is available for plan9. Bash could be ported, the version I use on a Unix flavor at work exceeds 1.5Mb and still makes calls on shared libraries. In fact anything could be ported, Plan9 comes with an Ansi POSIX Environment for compatibility. -- cg No this is a Plan9 issue. The rio windows don't understand cursor addressing, as no standard tool uses it. How would the shell redraw the input line then if you say go back in history? There is vt for emulating a vt100 if you absolutely need to... log in to a BBS... or run bash with command history... Plan9 people would say this is the task of the windowing system and not the shell anyways!
symbolic links: they were a hack - Unix thought it owned the file system Interesting, does plan9 provide some form of non-hacky equivalent? I've always viewed filesystems without symbolic link support as brain-damaged beyond any sort of real usefulness. Actually, I get violently annoyed and irritated at the mere memory, the slightest recall of dealings with such systems. I'll try to calm down now... -- AnonymousDonor The default path given to users is as simple as /bin and . - I always thought . was a bad thing, you might run some unanticipated program. Instead of creating symbolic or hard links, you mount all the commands you want into /bin. It allows you to say "mount this bit of filesystem in that place, so that the resulting directory contains both the new stuff and what was there before". This is (or, at least, can be) done per-process. There is a flag you can use to fork so that resulting processes can no longer alter their name spaces in any way. See NameSpaces. -- ChrisGarrod (who takes responsibility for most of this page)
I am highly unconvinced by the remarks above about command-line history. If your prompt is "$ ", say, do you really want to assume that every line that starts dollar-space is one you typed? (Hint: no.) If your prompt consists of the current directory followed by ">", what are you going to do? This approach just doesn't work. (It could be made to work if the contents of /mnt/wsys/text were represented in some marked-up form that distinguished between user input and system output, but that would be very un-plan9-ish.) -- GarethMcCaughan It's not Command Line History, it's Window History! Imagine having history built into every program you use for free. It's not just for shells anymore. The text of all of your windows can be found in /mnt/wsys/*/text where * means all windows, or you can use a regular expression for the number or a set of windows. -- ChrisGarrod Note that when using plan9 I've never found the need for all that grep /mnt/wsys/blahblah stuff. There is an even simpler solution: click to edit, and cut and paste. For example, suppose I write ls /some/long/path and get foo.c bar.c some_dir/ and now I want to tar up some_dir without retyping /some/long/path. I select ls and type tar c over it, then click after /some/long/path and type /some_dir | gzip >some_dir.tgz (I could cut and paste some_dir from the ls output, but it's not worth it if it's small). Then I select the line with the middle mouse button (which, under acme, copies the line to the bottom of the window and adds a newline, effectively executing it). It's so much simpler than remembering obscure bang syntax and counting how many commands ago the command I'm interested in happened. (no doubt ExtremeKeyboarding fans would consider this MouseAbuse compared to GnuReadline-style interaction) Yes, plan9 tar has different syntax from unix tar. There are two disadvantages I can think of. One is that you have to go find the command to edit. If it happened a long time ago you may have to scroll the window back some. This is not a problem for me because 1 - when using csh-style bang history I wind up scrolling back by hand anyway (who really remembers that the command they want to edit was 5 commands ago?), 2 - I almost always want to edit the previous or penultimate command line, and 3 - if I really want to find an old command I can use the acme text search function (right mouse click) (this is not available under a plain rio window). The second disadvantage is that you lose teletype hardcopy-like command history in your window, since you've been editing your old commands (reminds me of the algorists vs. abaccists). This can be annoying, but well worth the tradeoff considering that you can get rid of the giant buggy readline library linked into everything, obscure shell history syntax, and all the complicated tty modes and commands that make the giant buggy readline library possible. And of course with readline, you always find yourself using some program that didn't happen to have it linked in. Shell histories and gnu readline clearly are solving the problem in the wrong place, but that's simply a result of history since they grew up on teletypes and dumb terminals that emulated teletypes (text only gets written at the bottom of the screen, where the typewriter head is). But we have mice and bitmap screens and proportional fonts now, surely it's time to shed the historical glass tty baggage? Actually, this is what I mostly notice WhatIsNotInPlanNine: HistoricalBaggage. ---- That is a result of the team's MercilessRefactoring - again I am talking to myself Using bash in Linux, I use the up arrow to scroll back through the commands I've recently executed until I get to the one I want. I don't have to remember how many commands ago it was. I find this much more convenient than using the mouse could ever be. Using the mouse is slow. Bash hint: use the editors search function / to find the command you want. Regarding history and all you can go/scroll select, not part of the shell, etc... WTH? i need to use mouse for command entrance and accessing previous commands and stuff or use left/right to access previous lines and do something there? no just no, sorry but this is just stupid, not using best input device (keyboard) to its fullest is very very bad.
Contributors: AnonymousDonor, ChrisGarrod
CategoryOperatingSystem
Last edit February 4, 2012, See github about remodling.