Hello, 9fans! :)y's plan9port mod 1 version 1.0 is now out.
<magnet:?dn=sp9pm1v1p0.patch&xl=153045&xt=urn:sha1:DN75FAYWWBS54C3TL2DE7DTFMICT2GFX&xt=urn:md5:8B486B050E4FC7E054156CBB6194348C&xt=urn:crc32:909347387&as=http%3A%2F%2Fplan9.icebubble.org%2Fplan9port%2Fpatches%2Fsp9pm1v1p0.patch> <http://plan9.icebubble.org/plan9port/patches/sp9pm1v1p0.patch> Among its features: * The ./INSTALL script has been enhanced, to improve detection of failed compiles/installs by returning a non-zero exit code. This makes it easier for build scripts to detect incomplete builds, and to detect complete builds with fewer false positives. * Finally! A sane solution to the problem of hard-coded paths in the plan9port tree: Most of them have been removed, in favor of a "#!/usr/bin/env 9rc" approach (which execs "9 rc"). The "9" script has been updated with "intelligence" to detect and set $PLAN9 from miscellaneous clues in its environment. (Exec is used throughout, so no memory penalty is incurred.) Just a few hard-coded paths remain. One of them is in the "9" script, itself. The others (5, at last count) can be found in lib/moveplan9.files. OS X users should develop a habit (like Linux users) of setting their $PATH variables to include $PLAN9/bin, so some of the remaining hard-coded paths can be eliminated. * To facilitate the "9rc" mechanism, a few additional scripts have been added. "9awk" execs "9 awk", "9sed" execs "9 sed", etc. There's even a 9bash to make it easy to run bash scripts with $PLAN9 set to an appropriate value. There's also a "9fmt" to make it easier to run "|fmt" (which would otherwise have to be run as "|9 fmt") in Acme on plan9port. * Updates to documentation, including the install(1) page, install.txt, README, (9P) manual, and a number of other man pages. Documentation of more current command-line options, more gooder grammar, and clearer explanations. * vac and vacfs now support symbolic links, block and character devices, named pipes, Unix domain sockets, and inode change times (ctime), as well as set-user-id, set-group-id, and sticky bits. In theory, they also support append-only (DMAPPEND), exclusive-use (DMEXCL), and temporary (DMTMP) bits. However, due to lack of a native Plan 9 system, support for DMAPPEND, DMEXCL, and DMTMP has not been tested. Preliminary support in unvac for these file types and mode bits exists, but is still incomplete. 9pfuse has been updated to support those of the above attributes which can be exposed by 9P2000. So now you can have, for example, block devices and Unix domain sockets appear in your 9pfuse file systems. * Note: A number of changes were made to lib9, so almost all of p9p will need to be recompiled. Thanks to: * David du Colombier for showing me how to implement symbolic links. * rsc for creating the bowl of spaghetti which has been so much fun swimming in. ;) Notes on the changes to lib9: A ctime member was added to the Dir struct, so a file's citme can be passed around with the rest of the file's metadata on p9p systems. This changes sizeof(Dir), which is used by many programs, so programs relying on the old sizeof(Dir) have to be recompiled. The most significant change to lib9 is in the way the dirstat, dirread, and dirreadall functions handle symbolic links. Previously, symbolic links were dereferenced immediately upon being statted. However, this functionality was not implemented correctly. Although other file attributes correctly reflected the referent of the link, the file size was left as the size of the link (the number that a call to readlink would return), and the DMSYMLINK bit was left set in the file mode. I'm guessing that this was an early attempt to emulate Plan 9's namespace mechanism using symbolic links. The new approach is to NOT dereference symbolic links in dirstat and dirread[all], but to return stat data for the symbolic link itself. Since other functions, such as open, remove, etc., use the native library calls, which handle symbolic links according to Unix semantics, they still behave correctly. Since a walk through a symbolic link involves opening its referent and reading directory entries, walking through symlinked directories still works. The advantage of the new approach is that symlink metadata is now accessible in p9p's stat structure. Access to this metadata is necessary for vac(1) to store the correct atime, mtime, and ctime for a symlink in a vac archive. The potential drawback to this new way of handling symlinks is that programs which descend file heirarchies by checking only DMDIR will not follow symlinks automatically. (The du(1) command is a good example.) On Unix, this is typically the correct behavior. On Plan 9, recursive descent conventionally traverses namespace boundaries. But plan9port has one foot in the world of Unix and the other foot in the world of Plan 9, so it's hard to say which behavior is "correct" for plan9port. In general, I think plan9port programs should be prepared to encounter files of types other than ordinary files and directories (such as FIFOs, sockets, and symlinks). In du.c, for example, a simple dirfstat is all that's needed: if(followsymlinksoption && dir->qid.type&QTSYMLINK) dir = dirfstat(fd); Nevertheless, there is still merit to the idea of using symlinks to emulate Plan 9-style name spaces. So that functionality has also been implemented (correctly, this time, I think). You can choose which symlink paradigm a particular program should use by setting the variable $PLAN9_DEREF in its environment to one of the following values: PLAN9_DEREF="dirs" # deref only links to directories PLAN9_DEREF="nondirs" # deref links to all but directories PLAN9_DEREF="both" # deref all symlinks PLAN9_DEREF="none" # stat symlinks as symlinks If $PLAN9_DEREF is unset, null, or set to any other value, dirstat, dirread, and dirreadall will behave as if PLAN9_DEREF="none". Note that this setting controls only the behavior of the functions dirstat, dirread, and dirreadall, not other functions like open or remove, which continue to operate as they always have: a successful open still always dereferences symbolic links, and remove still never does. Notes on developing in Acme: This is the first project I've done in Acme. Some of my impressions of the experience follow. * Click-to-focus is just as annoying today as it was in 1995. Point-to-focus is cumbersome when used by small windows, such as Acme window tag lines. For tag lines, "sloppy" focus might be better, although it's unclear how sloppy focus and point-to-focus could be made to co-exist peacefully. * The ability to click and grab, or drag and grab, text (chording) is very useful. * Acme very frequently places new windows where I least want them, and with inconvenient sizes. This gets to be quite annoying after a while, encouraging workarounds that require extraneous clicking. * Having to switch a hand back and forth between the keyboard and mouse (or typing with one hand, while mousing with the other) is an annoyance. I suspect you really need three arms to use Acme efficiently. (For the record, I'm a touch-typist.) * Per recommendations from the Plan 9 community, I ordered an HP DY651A three-button USB optical mouse with no scroll wheel. (The actual mouse I received is labeled M-U0013-O, which I'm guessing is a synonymous part number.) This mouse is significantly smaller than my hand, and the middle button is not haptically distinguishable from the others. This means that chording requires fine motor skill, which is tedious pretty much from the get go. The other mouse recommended by the Plan 9 community, the IBM 40K9201, appears to have been discontinued and could not be found for purchase, even on the Internet. No three-button optical USB mice (ZERO! NONE!) without scroll wheels could be found in local computer shops or retail stores. * It's not easy to search one Acme window for a search string in another Acme window. * "New" and "win" are not in the default tag line for directory windows, but they should be. It would also be useful if the default tag line in "New" windows contained that directory name, as well as the text "Get". * Recalling/editing previous commands in "win" windows is tedious. * It's difficult to open files with odd characters in their names, such as '"' (double quote). The name has to be explicitly entered into a tag line; sweeping it with button 3 treats it as a search string, without first checking if it's the name of a file. * It's difficult to find the header/source file in which a particular function, variable, or macro is defined. Why can't Acme cross-reference such things, like other IDEs do? * Where did all my keyboard accelerators go? Acme could use Put, Undo, and Paste accelerators, at a minimum. Keystrokes for forward/backward word would be great, and a keystroke to warp the pointer to the end of the tag line would be really nice, too. * What command did I just run? When text is executed erroneously with button 2, Acme will show the error output, but not the command that was run. This can happen, for example, if the mouse moves unintentionally when you release button 2, while clicking or dragging text you want to execute. -- +---------------------------------------------------------------+ |Smiley <[email protected]> PGP key ID: BC549F8B | |Fingerprint: 9329 DB4A 30F5 6EDA D2BA 3489 DAB7 555A BC54 9F8B| +---------------------------------------------------------------+
