Re: [9fans] p9p: 9 ls /dev
Hello David, thanks for the response. > it may not be worth it I agree. I think it is wise to give up to simulate dirread() rigorously. plan9 is not unix. > Ori's suggestion to use Getdirentries64 on OSX might be better I cannot find getdirentries64() on my OSX. I examined david code and found the code have still some problems. (1) some directory entries are lost. (2) uid and gid is wrong. the test program is attached here. test_dirread.c Description: Binary data the result is shown below. # # ls (official ls in osx) # -bash$ ls /usr/bin|wc 110811089719 -bash$ ls /dev|wc 352 3522428 # # david # -bash$ mk -f mkfile_david 9c -D__DARWIN_64_BIT_INO_T test_dirread.c 9c -D__DARWIN_64_BIT_INO_T dirread_david2.c 9l -o o.test_dirread test_dirread.o dirread_david2.o -bash$ o.test_dirread . .DS_Store root 501 416 0 _mp9dir.c root 501 20320 0 _p9dir.c root 501 2000106 0 a.out root 501 710 0 a1.c root 501 572 0 b1.c root 501 243 0 dirread.c.orig root 501 743 0 dirread1.c root 501 137 0 dirread_david.c root 501 473 0 ... -bash$ o.test_dirread /usr/bin |wc 7703850 20936 -bash$ o.test_dirread -a /usr/bin |wc 7703850 20936 -bash$ o.test_dirread /dev |wc 32016007739 -bash$ o.test_dirread -a /dev |wc 32016007739 -bash$ # # mine # -bash$ mk 9c -D__DARWIN_64_BIT_INO_T test_dirread.c 9c -D__DARWIN_64_BIT_INO_T mdirread2.c 9c -D__DARWIN_64_BIT_INO_T _mp9dir.c 9l -o o.test_dirread test_dirread.o mdirread2.o _mp9dir.o -bash$ o.test_dirread . .DS_Store arisawa staff 644 6148 _mp9dir.c arisawa staff 644 4948 _mp9dir.o arisawa staff 644 10284 _p9dir.c arisawa staff 444 4733 a.out arisawa staff 755 9552 a1.c arisawa staff 644 741 b1.c arisawa staff 644 2390 dirread.c.orig arisawa staff 444 3699 dirread1.c arisawa staff 644 3790 dirread_david.c arisawa staff 644 3768 ... -bash$ o.test_dirread /usr/bin |wc 11085540 33034 -bash$ o.test_dirread -a /usr/bin |wc 11085540 33034 -bash$ o.test_dirread /dev |wc 3521760 10308 -bash$ o.test_dirread -a /dev |wc 3521760 10308 -bash$ David idea is nice. I borrowed the idea: dir = fdopendir(dup(fd)); in mdirread2.c mkfile Description: Binary data mdirread2.c Description: Binary data _mp9dir.c Description: Binary data NOTE on _p9dir.c (A) d->length I observed opening character device can make a problem. I think length of those device is allowed to assign 0. if(S_ISBLK(lst->st_mode) || S_ISCHR(lst->st_mode)){ if((fd = open(name, O_RDONLY)) >= 0){ d->length = disksize(fd, st); close(fd); } } (B) DMDEVICE you will find the code in _p9dir.c else if(S_ISBLK(st->st_mode)){ d->mode |= DMDEVICE; d->qid.path = ('b'<<16)|st->st_rdev; } else if(S_ISCHR(st->st_mode)){ d->mode |= DMDEVICE; d->qid.path = ('c'<<16)|st->st_rdev; } but I prefer else if(S_ISBLK(st->st_mode)){ d->mode |= DMBLOCK; d->qid.path = ('b'<<16)|st->st_rdev; } else if(S_ISCHR(st->st_mode)){ d->mode |= DMCHAR; d->qid.path = ('c'<<16)|st->st_rdev; } (C) I fixed some codes that produce wrong uid and gid. comments welcome > 2017/04/12 16:05、David Arroyoのメール: > > The problem is twofold; > > * The function exits early if it can't read a max-length directory > entry, so that entry is "skipped" in subsequent calls to mygetdents. > * As you said, we also lose any buffered dirents that haven't been > returned from readdir yet. > > I think these are both fixable problems, but it may not be worth it. > Ori's suggestion to use Getdirentries64 on OSX might be better. > > David > > On Tue, Apr 11, 2017, at 10:33 PM, arisawa wrote: >> I did more test on david code and found a problem. >> >> -bash$ mk -f mkfile_david >> -bash$ o.test_dirread -a /usr/bin |wc >>10844336 27266 >> -bash$ o.test_dirread /usr/bin |wc >>10844336 27266 >> -bash$ ls /usr/bin |wc >>110811089719 >> >> option -a is for dirreadall. >> 1108 - 1084 entries are lost. >> >> they are: >> o.test_dirread /usr/bin | awk '{print $1}' | sort >/tmp/a >> ls /usr/bin | sort >/tmp/b >> diff /tmp/a /tmp/b >> >> -bash$ diff /tmp/a /tmp/b >> 21a22 >>> SplitForks >> 240a242,246 >>> easy_install-2.6 >>> easy_install-2.7 >>> efax >>> efix >>> egrep >> 461a468,473 >>> kcc >>> kdestroy >>> kextutil >>> keytool >>> kgetcred >>> kill.d >> 675a688,694 >>> piconv >>> piconv5.16 >>> piconv5.18 >>> pidpersec.d >>> pkgbuild >>> pkill >>> pl >> 880a900,904 >>> spfquery5.18 >>> splain >>> splain5.16 >>>
Re: [9fans] p9p: 9 ls /dev
The problem is twofold; * The function exits early if it can't read a max-length directory entry, so that entry is "skipped" in subsequent calls to mygetdents. * As you said, we also lose any buffered dirents that haven't been returned from readdir yet. I think these are both fixable problems, but it may not be worth it. Ori's suggestion to use Getdirentries64 on OSX might be better. David On Tue, Apr 11, 2017, at 10:33 PM, arisawa wrote: > I did more test on david code and found a problem. > > -bash$ mk -f mkfile_david > -bash$ o.test_dirread -a /usr/bin |wc > 10844336 27266 > -bash$ o.test_dirread /usr/bin |wc > 10844336 27266 > -bash$ ls /usr/bin |wc > 110811089719 > > option -a is for dirreadall. > 1108 - 1084 entries are lost. > > they are: > o.test_dirread /usr/bin | awk '{print $1}' | sort >/tmp/a > ls /usr/bin | sort >/tmp/b > diff /tmp/a /tmp/b > > -bash$ diff /tmp/a /tmp/b > 21a22 > > SplitForks > 240a242,246 > > easy_install-2.6 > > easy_install-2.7 > > efax > > efix > > egrep > 461a468,473 > > kcc > > kdestroy > > kextutil > > keytool > > kgetcred > > kill.d > 675a688,694 > > piconv > > piconv5.16 > > piconv5.18 > > pidpersec.d > > pkgbuild > > pkill > > pl > 880a900,904 > > spfquery5.18 > > splain > > splain5.16 > > splain5.18 > > split > > sorry if I make a mistake, but I suspect readdir_r() has a buffer, > which can make a problem in using dup(). > > Kenji Arisawa. > > > 2017/04/09 13:18、arisawaのメール: > > > > thanks david. > > > > using dup() is very nice idea! > > your code works with > > CFLAGS=-D__DARWIN_64_BIT_INO_T# manual is wrong > > and a fix: > > // buf = ((char*)buf) + d_reclen(buf); > > buf = (struct dirent *)(((char*)buf) + d_reclen(buf)); > > and adding > > #define NAME_MAX 256 > > in somewhere. > > > > now /dev is readable. > > > > one problem is left. > > > > my test code: > > fd = open(dirname,OREAD); > > if(fd < 0) > > fatal("%s open error",dirname); > > while((n = dirread(fd, )) > 0){ > > print("#DBG n=%d\n",n); > > for(i = 0; i < n; i++) > > print("%s %s %s \n", db[i].name, db[i].uid, db[i].gid); > > } > > close(fd); > > shows for dirname=$HOME > > ... > > arch root 501 > > bin root 501 > > ... > > but they should be > > arch arisawa staff > > bin arisawa staff > > this problem comes from _p9dir() that is used in dirpackage(). > > > > Kenji Arisawa > > > > > >> 2017/04/08 18:07、David Arroyo のメール: > >> > >> Ignore my previous post, I was tired and forgot about dup(). How about > >> something like this? (attached) > >> > >> I only tested this on Ubuntu, I don't have an OS X machine. I still went > >> with readdir_r because the AIX and Solaris man pages for readdir were > >> vague about its behavior when called from multiple threads (glibc, musl, > >> FreeBSD look pretty safe). > >> > >> Cheers, > >> David > >> > >> On Sat, Apr 8, 2017, at 03:27 AM, David Arroyo wrote: > >>> This should be doable with some combination of fdopendir(3) and > >>> readdir(3). I'm not sure how to avoid leaking memory through the > >>> returned DIR pointer and any memory allocated with by readdir(3). > >>> This is usually free'd by closedir(3), which we can't use without > >>> closing the underlying file. > >>> > >>> It should be OK to use free() on the return value of fdopendir, and > >>> stick to the uglier readdir_r(3) interface. I can definitely see why > >>> Russ went with the simpler system-specific interfaces on this. > >>> > >>> David > >>> > >>> On Sat, Apr 8, 2017, at 02:46 AM, Ori Bernstein wrote: > On Sat, 8 Apr 2017 15:21:47 +0900, arisawa wrote: > > > but how to? > > > > unix doesn’t have something like fdreaddir(int fd). > > my guess: russ unwillingly used a low level function such as > > int getdirentries(int fd, char *buf, int nbytes, long *basep). > > > > readdirall() might be OK in regular usage. > > I don't use OSX regularly, although I do maintain the syscall > layer for Myrddin on it. > > Getdirentries64 exists, and rudimentary testing doesn't show > any difficulties with using it. > > -- > Ori Bernstein > > >>> > >> > > > > diff --git a/src/lib9/dirread.c b/src/lib9/dirread.c index 40fbe3c..3b70938 100644 --- a/src/lib9/dirread.c +++ b/src/lib9/dirread.c @@ -6,46 +6,6 @@ extern int _p9dir(struct stat*, struct stat*, char*, Dir*, char**, char*); -#if defined(__linux__) -static int -mygetdents(int fd, struct dirent *buf, int n) -{ - off_t off; - int nn; - - /* This doesn't match the man page, but it works in Debian with a 2.2 kernel */ - off = p9seek(fd, 0, 1); - nn = getdirentries(fd, (void*)buf, n, ); - return nn; -} -#elif defined(__APPLE__) -static int -mygetdents(int fd, struct dirent
Re: [9fans] p9p: 9 ls /dev
I did more test on david code and found a problem. -bash$ mk -f mkfile_david -bash$ o.test_dirread -a /usr/bin |wc 10844336 27266 -bash$ o.test_dirread /usr/bin |wc 10844336 27266 -bash$ ls /usr/bin |wc 110811089719 option -a is for dirreadall. 1108 - 1084 entries are lost. they are: o.test_dirread /usr/bin | awk '{print $1}' | sort >/tmp/a ls /usr/bin | sort >/tmp/b diff /tmp/a /tmp/b -bash$ diff /tmp/a /tmp/b 21a22 > SplitForks 240a242,246 > easy_install-2.6 > easy_install-2.7 > efax > efix > egrep 461a468,473 > kcc > kdestroy > kextutil > keytool > kgetcred > kill.d 675a688,694 > piconv > piconv5.16 > piconv5.18 > pidpersec.d > pkgbuild > pkill > pl 880a900,904 > spfquery5.18 > splain > splain5.16 > splain5.18 > split sorry if I make a mistake, but I suspect readdir_r() has a buffer, which can make a problem in using dup(). Kenji Arisawa. > 2017/04/09 13:18、arisawaのメール: > > thanks david. > > using dup() is very nice idea! > your code works with > CFLAGS=-D__DARWIN_64_BIT_INO_T # manual is wrong > and a fix: > //buf = ((char*)buf) + d_reclen(buf); > buf = (struct dirent *)(((char*)buf) + d_reclen(buf)); > and adding > #define NAME_MAX 256 > in somewhere. > > now /dev is readable. > > one problem is left. > > my test code: > fd = open(dirname,OREAD); > if(fd < 0) > fatal("%s open error",dirname); > while((n = dirread(fd, )) > 0){ > print("#DBG n=%d\n",n); > for(i = 0; i < n; i++) > print("%s %s %s \n", db[i].name, db[i].uid, db[i].gid); > } > close(fd); > shows for dirname=$HOME > ... > arch root 501 > bin root 501 > ... > but they should be > arch arisawa staff > bin arisawa staff > this problem comes from _p9dir() that is used in dirpackage(). > > Kenji Arisawa > > >> 2017/04/08 18:07、David Arroyo のメール: >> >> Ignore my previous post, I was tired and forgot about dup(). How about >> something like this? (attached) >> >> I only tested this on Ubuntu, I don't have an OS X machine. I still went >> with readdir_r because the AIX and Solaris man pages for readdir were >> vague about its behavior when called from multiple threads (glibc, musl, >> FreeBSD look pretty safe). >> >> Cheers, >> David >> >> On Sat, Apr 8, 2017, at 03:27 AM, David Arroyo wrote: >>> This should be doable with some combination of fdopendir(3) and >>> readdir(3). I'm not sure how to avoid leaking memory through the >>> returned DIR pointer and any memory allocated with by readdir(3). >>> This is usually free'd by closedir(3), which we can't use without >>> closing the underlying file. >>> >>> It should be OK to use free() on the return value of fdopendir, and >>> stick to the uglier readdir_r(3) interface. I can definitely see why >>> Russ went with the simpler system-specific interfaces on this. >>> >>> David >>> >>> On Sat, Apr 8, 2017, at 02:46 AM, Ori Bernstein wrote: On Sat, 8 Apr 2017 15:21:47 +0900, arisawa wrote: > but how to? > > unix doesn’t have something like fdreaddir(int fd). > my guess: russ unwillingly used a low level function such as > int getdirentries(int fd, char *buf, int nbytes, long *basep). > > readdirall() might be OK in regular usage. I don't use OSX regularly, although I do maintain the syscall layer for Myrddin on it. Getdirentries64 exists, and rudimentary testing doesn't show any difficulties with using it. -- Ori Bernstein >>> >> >
Re: [9fans] p9p: 9 ls /dev
thanks david. using dup() is very nice idea! your code works with CFLAGS=-D__DARWIN_64_BIT_INO_T # manual is wrong and a fix: // buf = ((char*)buf) + d_reclen(buf); buf = (struct dirent *)(((char*)buf) + d_reclen(buf)); and adding #define NAME_MAX 256 in somewhere. now /dev is readable. one problem is left. my test code: fd = open(dirname,OREAD); if(fd < 0) fatal("%s open error",dirname); while((n = dirread(fd, )) > 0){ print("#DBG n=%d\n",n); for(i = 0; i < n; i++) print("%s %s %s \n", db[i].name, db[i].uid, db[i].gid); } close(fd); shows for dirname=$HOME ... arch root 501 bin root 501 ... but they should be arch arisawa staff bin arisawa staff this problem comes from _p9dir() that is used in dirpackage(). Kenji Arisawa > 2017/04/08 18:07、David Arroyoのメール: > > Ignore my previous post, I was tired and forgot about dup(). How about > something like this? (attached) > > I only tested this on Ubuntu, I don't have an OS X machine. I still went > with readdir_r because the AIX and Solaris man pages for readdir were > vague about its behavior when called from multiple threads (glibc, musl, > FreeBSD look pretty safe). > > Cheers, > David > > On Sat, Apr 8, 2017, at 03:27 AM, David Arroyo wrote: >> This should be doable with some combination of fdopendir(3) and >> readdir(3). I'm not sure how to avoid leaking memory through the >> returned DIR pointer and any memory allocated with by readdir(3). >> This is usually free'd by closedir(3), which we can't use without >> closing the underlying file. >> >> It should be OK to use free() on the return value of fdopendir, and >> stick to the uglier readdir_r(3) interface. I can definitely see why >> Russ went with the simpler system-specific interfaces on this. >> >> David >> >> On Sat, Apr 8, 2017, at 02:46 AM, Ori Bernstein wrote: >>> On Sat, 8 Apr 2017 15:21:47 +0900, arisawa wrote: >>> but how to? unix doesn’t have something like fdreaddir(int fd). my guess: russ unwillingly used a low level function such as int getdirentries(int fd, char *buf, int nbytes, long *basep). readdirall() might be OK in regular usage. >>> >>> I don't use OSX regularly, although I do maintain the syscall >>> layer for Myrddin on it. >>> >>> Getdirentries64 exists, and rudimentary testing doesn't show >>> any difficulties with using it. >>> >>> -- >>>Ori Bernstein >>> >> >
Re: [9fans] p9p: 9 ls /dev
Ignore my previous post, I was tired and forgot about dup(). How about something like this? (attached) I only tested this on Ubuntu, I don't have an OS X machine. I still went with readdir_r because the AIX and Solaris man pages for readdir were vague about its behavior when called from multiple threads (glibc, musl, FreeBSD look pretty safe). Cheers, David On Sat, Apr 8, 2017, at 03:27 AM, David Arroyo wrote: > This should be doable with some combination of fdopendir(3) and > readdir(3). I'm not sure how to avoid leaking memory through the > returned DIR pointer and any memory allocated with by readdir(3). > This is usually free'd by closedir(3), which we can't use without > closing the underlying file. > > It should be OK to use free() on the return value of fdopendir, and > stick to the uglier readdir_r(3) interface. I can definitely see why > Russ went with the simpler system-specific interfaces on this. > > David > > On Sat, Apr 8, 2017, at 02:46 AM, Ori Bernstein wrote: > > On Sat, 8 Apr 2017 15:21:47 +0900, arisawawrote: > > > > > but how to? > > > > > > unix doesn’t have something like fdreaddir(int fd). > > > my guess: russ unwillingly used a low level function such as > > > int getdirentries(int fd, char *buf, int nbytes, long *basep). > > > > > > readdirall() might be OK in regular usage. > > > > I don't use OSX regularly, although I do maintain the syscall > > layer for Myrddin on it. > > > > Getdirentries64 exists, and rudimentary testing doesn't show > > any difficulties with using it. > > > > -- > > Ori Bernstein > > > diff --git a/src/lib9/dirread.c b/src/lib9/dirread.c index 40fbe3c..6c00dff 100644 --- a/src/lib9/dirread.c +++ b/src/lib9/dirread.c @@ -3,54 +3,46 @@ #include #include #include +#include extern int _p9dir(struct stat*, struct stat*, char*, Dir*, char**, char*); -#if defined(__linux__) +#if defined(__DragonFly__) +static inline int d_reclen(struct dirent *de) { return _DIRENT_DIRSIZ(de); } +#else +static inline int d_reclen(struct dirent *de) { return de->d_reclen; } +#endif + static int mygetdents(int fd, struct dirent *buf, int n) { - off_t off; - int nn; + int err, nn; + DIR *dirp; + + /* use to calculate max size of a dirent */ + struct dirent de; + int max_sz = (sizeof de - sizeof de.d_name) + NAME_MAX + 1; + + if ((dirp = fdopendir(dup(fd))) == nil) + return -1; - /* This doesn't match the man page, but it works in Debian with a 2.2 kernel */ - off = p9seek(fd, 0, 1); - nn = getdirentries(fd, (void*)buf, n, ); + nn = 0; + while(n >= max_sz){ + if ((err = readdir_r(dirp, buf, )) != 0){ + errno = err; + if(nn == 0) + nn = -1; + break; + } + if (buf == nil) + break; + nn += d_reclen(buf); + n -= d_reclen(buf); + buf = ((char*)buf) + d_reclen(buf); + } + closedir(dirp); return nn; } -#elif defined(__APPLE__) -static int -mygetdents(int fd, struct dirent *buf, int n) -{ - long off; - return getdirentries(fd, (void*)buf, n, ); -} -#elif defined(__FreeBSD__) || defined(__DragonFly__) -static int -mygetdents(int fd, struct dirent *buf, int n) -{ - off_t off; - return getdirentries(fd, (void*)buf, n, ); -} -#elif defined(__sun__) || defined(__NetBSD__) || defined(__OpenBSD__) -static int -mygetdents(int fd, struct dirent *buf, int n) -{ - return getdents(fd, (void*)buf, n); -} -#elif defined(__AIX__) -static int -mygetdents(int fd, struct dirent *buf, int n) -{ - return getdirent(fd, (void*)buf, n); -} -#endif - -#if defined(__DragonFly__) -static inline int d_reclen(struct dirent *de) { return _DIRENT_DIRSIZ(de); } -#else -static inline int d_reclen(struct dirent *de) { return de->d_reclen; } -#endif static int countde(char *p, int n)
Re: [9fans] p9p: 9 ls /dev
This should be doable with some combination of fdopendir(3) and readdir(3). I'm not sure how to avoid leaking memory through the returned DIR pointer and any memory allocated with by readdir(3). This is usually free'd by closedir(3), which we can't use without closing the underlying file. It should be OK to use free() on the return value of fdopendir, and stick to the uglier readdir_r(3) interface. I can definitely see why Russ went with the simpler system-specific interfaces on this. David On Sat, Apr 8, 2017, at 02:46 AM, Ori Bernstein wrote: > On Sat, 8 Apr 2017 15:21:47 +0900, arisawawrote: > > > but how to? > > > > unix doesn’t have something like fdreaddir(int fd). > > my guess: russ unwillingly used a low level function such as > > int getdirentries(int fd, char *buf, int nbytes, long *basep). > > > > readdirall() might be OK in regular usage. > > I don't use OSX regularly, although I do maintain the syscall > layer for Myrddin on it. > > Getdirentries64 exists, and rudimentary testing doesn't show > any difficulties with using it. > > -- > Ori Bernstein >
Re: [9fans] p9p: 9 ls /dev
On Sat, 8 Apr 2017 15:21:47 +0900, arisawawrote: > but how to? > > unix doesn’t have something like fdreaddir(int fd). > my guess: russ unwillingly used a low level function such as > int getdirentries(int fd, char *buf, int nbytes, long *basep). > > readdirall() might be OK in regular usage. I don't use OSX regularly, although I do maintain the syscall layer for Myrddin on it. Getdirentries64 exists, and rudimentary testing doesn't show any difficulties with using it. -- Ori Bernstein
Re: [9fans] p9p: 9 ls /dev
but how to? unix doesn’t have something like fdreaddir(int fd). my guess: russ unwillingly used a low level function such as int getdirentries(int fd, char *buf, int nbytes, long *basep). readdirall() might be OK in regular usage. > 2017/04/08 13:06、Lyndon Nerenbergのメール: > > >> On Apr 7, 2017, at 6:18 PM, arisawa wrote: >> >> the problem comes from getdirentries() used in $P9P/src/lib9/dirread.c, I >> think. >> >> man getdirentries(2) of OSX says: > > And, dare I quote a Linux manpage, but getdirentries(3) there says: > >> CONFORMING TO >> Not in POSIX.1-2001. Present on the BSDs, and a few other systems. >> Use opendir(3) and readdir(3) instead. > > The fix should be simple enough. > > --lyndon > >
Re: [9fans] p9p: 9 ls /dev
> On Apr 7, 2017, at 6:18 PM, arisawawrote: > > the problem comes from getdirentries() used in $P9P/src/lib9/dirread.c, I > think. > > man getdirentries(2) of OSX says: And, dare I quote a Linux manpage, but getdirentries(3) there says: > CONFORMING TO >Not in POSIX.1-2001. Present on the BSDs, and a few other systems. >Use opendir(3) and readdir(3) instead. The fix should be simple enough. --lyndon
Re: [9fans] p9p: 9 ls /dev
thanks for response. the problem comes from getdirentries() used in $P9P/src/lib9/dirread.c, I think. man getdirentries(2) of OSX says: NOTES getdirentries() should rarely be used directly; instead, opendir(3) and readdir(3) should be used. As of Mac OS X 10.6, getdirentries() is deprecated, and it is recommended that applications use readdir(3) rather than using getdirentries() directly. Due to limitations with the system call, getdirentries() will not work with 64-bit inodes; in order to use getdirentries(), _DARWIN_NO_64_BIT_INODE must be defined. See stat(2) for more information on _DARWIN_NO_64_BIT_INODE and its other effects. > 2017/04/07 10:18、Lyndon Nerenbergのメール: > > >> On Apr 6, 2017, at 5:49 AM, arisawa wrote: >> >> on my system (on osx(10.10 and 10.11) with plan9port-20140306 (latest port >> from russ)) >> the next command fails. that is, >> 9 ls /dev >> does not return to shell. > > It also hangs on my 10.12.4 system. Mind you, I haven't updated/rebuilt P9P > on this machine is a long time ... > >
Re: [9fans] p9p: 9 ls /dev
> On Apr 6, 2017, at 5:49 AM, arisawawrote: > > on my system (on osx(10.10 and 10.11) with plan9port-20140306 (latest port > from russ)) > the next command fails. that is, > 9 ls /dev > does not return to shell. It also hangs on my 10.12.4 system. Mind you, I haven't updated/rebuilt P9P on this machine is a long time ...