s***@icebubble.org
2012-01-23 08:58:14 UTC
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.
:)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 <***@icebubble.org> PGP key ID: BC549F8B |
|Fingerprint: 9329 DB4A 30F5 6EDA D2BA 3489 DAB7 555A BC54 9F8B|
+---------------------------------------------------------------+
+---------------------------------------------------------------+
|Smiley <***@icebubble.org> PGP key ID: BC549F8B |
|Fingerprint: 9329 DB4A 30F5 6EDA D2BA 3489 DAB7 555A BC54 9F8B|
+---------------------------------------------------------------+