[9fans] test
test -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tc9a6987fe1ae85d1-M5855419eeac78ec30d7ccd62 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] `test -x` returns wrong results for directories
On Mon, Jun 8, 2020, at 3:13 AM, Charles Forsyth wrote: >> "search" is exactly the wrong word for what this bit does, because if you >> don't have "search" permission, the one thing you can still do is look at >> the names. > > in ramfs, but that's a bug that no-one had noticed oh it's the same in cwfs and in linux. if i remember right, (and i think i do,) it's always been this way in linux. (tried linux tmpfs recently, but i think permissions are enforced by the kernel 'over there', and i'm pretty sure it was the same on ext2 in linux 2.0.) i'd try some other unixes, but i have too much work to do today. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tdd7a9b1b32d01f54-M7b2a2c3581f03b37fca88b23 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] `test -x` returns wrong results for directories
I see I'd misapplied the rule in walk(5) so fossil is fine. It has to do with searching from . when you are there, which makes sense, not when entering the directory from its parent, so ignore that part of my earlier post. On Mon, Jun 8, 2020 at 3:13 AM Charles Forsyth wrote: > "search" is exactly the wrong word for what this bit does, because if you >> don't have "search" permission, the one thing you can still do is look at >> the names. > > > in ramfs, but that's a bug that no-one had noticed > > On Mon, Jun 8, 2020 at 3:05 AM wrote: > >> >>> So, cd'ing into a directory withut +x leads >> >>> to an inescapabler trap. >> >> ... >> >> fossil just moved up another notch in my estimation because directory >> search restriction is so broken. >> > >> > o...@eigenstate.org, what version of fossil were your experiments done >> on? >> > My observations are different: >> > >> > term% mkdir -p d/a/b >> > term% touch d/x >> > term% chmod -x d >> > term% ls -ld d >> > d-rw-r--r-- M 12 miller miller 0 Jun 7 16:38 d >> > term% cd d >> > term% cd .. >> > term% ls d >> > d/a >> > d/x >> > term% >> > >> > No trap that I can see here. >> >> cwfs, but -- yeah, it's enforced inconsistently across >> different file systems. (of course). >> -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tdd7a9b1b32d01f54-M39749150e29409f155014124 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] `test -x` returns wrong results for directories
> > "search" is exactly the wrong word for what this bit does, because if you > don't have "search" permission, the one thing you can still do is look at > the names. in ramfs, but that's a bug that no-one had noticed On Mon, Jun 8, 2020 at 3:05 AM wrote: > >>> So, cd'ing into a directory withut +x leads > >>> to an inescapabler trap. > >> ... > >> fossil just moved up another notch in my estimation because directory > search restriction is so broken. > > > > o...@eigenstate.org, what version of fossil were your experiments done > on? > > My observations are different: > > > > term% mkdir -p d/a/b > > term% touch d/x > > term% chmod -x d > > term% ls -ld d > > d-rw-r--r-- M 12 miller miller 0 Jun 7 16:38 d > > term% cd d > > term% cd .. > > term% ls d > > d/a > > d/x > > term% > > > > No trap that I can see here. > > cwfs, but -- yeah, it's enforced inconsistently across > different file systems. (of course). > -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tdd7a9b1b32d01f54-M8e0db3a8ea1ca83dc1cd64b9 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] `test -x` returns wrong results for directories
>>> So, cd'ing into a directory withut +x leads >>> to an inescapabler trap. >> ... >> fossil just moved up another notch in my estimation because directory search >> restriction is so broken. > > o...@eigenstate.org, what version of fossil were your experiments done on? > My observations are different: > > term% mkdir -p d/a/b > term% touch d/x > term% chmod -x d > term% ls -ld d > d-rw-r--r-- M 12 miller miller 0 Jun 7 16:38 d > term% cd d > term% cd .. > term% ls d > d/a > d/x > term% > > No trap that I can see here. cwfs, but -- yeah, it's enforced inconsistently across different file systems. (of course). -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tdd7a9b1b32d01f54-M9cf36356f4d9761339774af6 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] `test -x` returns wrong results for directories
>> So, cd'ing into a directory withut +x leads >> to an inescapabler trap. > ... > fossil just moved up another notch in my estimation because directory search > restriction is so broken. o...@eigenstate.org, what version of fossil were your experiments done on? My observations are different: term% mkdir -p d/a/b term% touch d/x term% chmod -x d term% ls -ld d d-rw-r--r-- M 12 miller miller 0 Jun 7 16:38 d term% cd d term% cd .. term% ls d d/a d/x term% No trap that I can see here. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tdd7a9b1b32d01f54-M8f53bea0a938aa0402f11d9d Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] `test -x` returns wrong results for directories
On Sat, Jun 6, 2020, at 10:13 PM, o...@eigenstate.org wrote: > > it's open() which is failing. i suppose it should. > > > > if the open fails, maybe access should stat the file, and if it's a > > directory, try dirread(2). or maybe just opening it for reading will > > work. i don't know, i'm new to this bit of plan 9 & i haven't slept. > > This is a bit subtle, though -- if you want > to check if *you* can traverse the directory, > then simply checking for an execute bit isn't > enough -- you need to check that you belong to > a group that has the execute bit. > > On a related note, execute permission seems > to behave strangely in general. You can create > a directory and list it: > > > Even without execute permission it's listable. > Makes sense. sarcasm? i've been confused about search permission since my earliest linux use where i experimented with permissions to see what, exactly, they did. it made no sense then, even without plan 9 leaving permission checks up to the individual filesystems. (this would have been linux 2.0.0) > > cpu% mkdir -p d/a/b > cpu% touch d/x > cpu% chmod -x d > cpu% ls -ld d > d-rw-r--r-- M 81 ori ori 0 Jun 5 07:53 d > cpu% ls d > d/a > d/x > > As expected, it can't be traversed: > > cpu% ls d/x > ls: d/x: 'd/x' does not exist > > But, you can cd into it: > > cpu% cd d > > And list '.': > > cpu% ls > a > x > cpu% ls . > a > x > > Can't traverse it to list subdirectories, > though: > > ls a > ls: a: 'a' access permission denied > cd a > Can't cd a: 'a' access permission denied > cpu% cd .. > Can't cd ..: '..' access permission denied > > So, cd'ing into a directory withut +x leads > to an inescapabler trap. > > Perhaps 'cd' should prevent entering that > directory. thanks for your analysis too, although you didn't say what filesystem you're using. i had to laugh at that trap; doesn't software get ridiculous sometimes? but it made me think, because charles said fossil doesn't handle the execute bit properly. perhaps once plan 9 went open source & had a public contrib, someone made just such a trap in contrib and fossil's permission handling was changed to stop it happening again. regardless of the cause, fossil just moved up another notch in my estimation because directory search restriction is so broken. i just checked linux 2.6.30. (old vm i had handy.) it's much like you describe except there is no trap. cd is indeed prevented and if you're in the directory when "search" permission is revoked, you can't list it but you can `cd ..`. "search" is exactly the wrong word for what this bit does, because if you don't have "search" permission, the one thing you can still do is look at the names... which lets you search them! it's more like "permission to open the display case and touch the things inside" or "permission to step over the museum's rope barriers". -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tdd7a9b1b32d01f54-Mce9e440c1218f5ab33129df6 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] `test -x` returns wrong results for directories
On Sat, Jun 6, 2020, at 2:25 PM, Charles Forsyth wrote: > execute permission on files, meaning here non-directories, is a special > variant of read. a file with mode 0111 can be opened with OEXEC and read(2) > will work as well as exec(2), > but can't be opened with OREAD, because it's not got any of 0444 set. bits > 0111 distinguish a file with contents that are intended to be executed once > read from files with only 0444 that do not contain executable content. > you wouldn't want every readable file to be executable (especially if you've > used systems that didn't have that distinction). > on the other hand, in a distributed file system, the client needs the > contents of the file to run it (whether code or #!script) so it needs to be > able to read files with just OEXEC. > I suppose the rule could have been that it would need mode 5 (r+x) to make > clear that the file was also readable, but it isn't. > > that OEXEC allows reading isn't true for a directory because exec means > "search", so if it's mode 0111 (say) you can chdir into it but not read the > names within it. > if you know a name of a file in that directory, though, you can still open > that. that's entirely enforced by the server. > > as the bug in access(2) suggests, only the server knows whether access should > be granted, and the open call gets it to do that, > but it doesn't work for OEXEC for directories as others have noted. perhaps > stat+chdir is the most accurate test, since you need x (search) permission to > walk(5) into a directory, > but the caller won't thank you for the chdir (and there's no easy or certain > way back), and ... that restriction isn't enforced by fossil or ramfs. (ramfs > wrongly allows you to read a directory that's mode 0.) > > probably the best thing is just to ignore the owner/group/other distinction, > and if the open(...OEXEC) fails, dirstat it, and if it's a directory with any > of 0111 set, it's fine (a little better than now). thanks for the analysis, charles. the dirstat you suggest wouldn't do any good for my case because rc-httpd runs as user none. the common problem it's trying to catch is a directory which isn't world-readable & world-searchable. 770 750 and 700 are common permissions. perhaps i should have rc-httpd just run the commands and test their status rather than trying to test ahead of time, but this would somewhat spoil the neat and simple design. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tdd7a9b1b32d01f54-M84c47e7be623cb8feb49865e Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] `test -x` returns wrong results for directories
> it's open() which is failing. i suppose it should. > > if the open fails, maybe access should stat the file, and if it's a > directory, try dirread(2). or maybe just opening it for reading will > work. i don't know, i'm new to this bit of plan 9 & i haven't slept. This is a bit subtle, though -- if you want to check if *you* can traverse the directory, then simply checking for an execute bit isn't enough -- you need to check that you belong to a group that has the execute bit. On a related note, execute permission seems to behave strangely in general. You can create a directory and list it: Even without execute permission it's listable. Makes sense. cpu% mkdir -p d/a/b cpu% touch d/x cpu% chmod -x d cpu% ls -ld d d-rw-r--r-- M 81 ori ori 0 Jun 5 07:53 d cpu% ls d d/a d/x As expected, it can't be traversed: cpu% ls d/x ls: d/x: 'd/x' does not exist But, you can cd into it: cpu% cd d And list '.': cpu% ls a x cpu% ls . a x Can't traverse it to list subdirectories, though: ls a ls: a: 'a' access permission denied cd a Can't cd a: 'a' access permission denied cpu% cd .. Can't cd ..: '..' access permission denied So, cd'ing into a directory withut +x leads to an inescapabler trap. Perhaps 'cd' should prevent entering that directory. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tdd7a9b1b32d01f54-M7606288952deb77ff6f74eca Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] `test -x` returns wrong results for directories
execute permission on files, meaning here non-directories, is a special variant of read. a file with mode 0111 can be opened with OEXEC and read(2) will work as well as exec(2), but can't be opened with OREAD, because it's not got any of 0444 set. bits 0111 distinguish a file with contents that are intended to be executed once read from files with only 0444 that do not contain executable content. you wouldn't want every readable file to be executable (especially if you've used systems that didn't have that distinction). on the other hand, in a distributed file system, the client needs the contents of the file to run it (whether code or #!script) so it needs to be able to read files with just OEXEC. I suppose the rule could have been that it would need mode 5 (r+x) to make clear that the file was also readable, but it isn't. that OEXEC allows reading isn't true for a directory because exec means "search", so if it's mode 0111 (say) you can chdir into it but not read the names within it. if you know a name of a file in that directory, though, you can still open that. that's entirely enforced by the server. as the bug in access(2) suggests, only the server knows whether access should be granted, and the open call gets it to do that, but it doesn't work for OEXEC for directories as others have noted. perhaps stat+chdir is the most accurate test, since you need x (search) permission to walk(5) into a directory, but the caller won't thank you for the chdir (and there's no easy or certain way back), and ... that restriction isn't enforced by fossil or ramfs. (ramfs wrongly allows you to read a directory that's mode 0.) probably the best thing is just to ignore the owner/group/other distinction, and if the open(...OEXEC) fails, dirstat it, and if it's a directory with any of 0111 set, it's fine (a little better than now). On Sat, Jun 6, 2020 at 7:38 AM Ethan Gardener wrote: > On Fri, Jun 5, 2020, at 8:22 PM, Richard Miller wrote: > > Looks to me like access(2) is not doing the right thing for directory > > execute (=search) permission. > > thanks for the tip. access is a very simple function. it doesn't do the > right thing, but there's a reason: > > BUGS > Since file permissions are checked by the server and group > information is not known to the client, access must open the > file to check permissions. (It calls stat(2) to check sim- > ple existence.) > > it's open() which is failing. i suppose it should. > > if the open fails, maybe access should stat the file, and if it's a > directory, try dirread(2). or maybe just opening it for reading will work. > i don't know, i'm new to this bit of plan 9 & i haven't slept. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tdd7a9b1b32d01f54-M873b037de0ec96e4b493d3d7 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] `test -x` returns wrong results for directories
On Sat, Jun 6, 2020 at 9:38 AM Ethan Gardener wrote:
>
> On Fri, Jun 5, 2020, at 8:22 PM, Richard Miller wrote:
> > Looks to me like access(2) is not doing the right thing for directory
> > execute (=search) permission.
>
> thanks for the tip. access is a very simple function. it doesn't do the right
> thing, but there's a reason:
>
> BUGS
> Since file permissions are checked by the server and group
> information is not known to the client, access must open the
> file to check permissions. (It calls stat(2) to check sim-
> ple existence.)
>
> it's open() which is failing. i suppose it should.
>
> if the open fails, maybe access should stat the file, and if it's a
> directory, try dirread(2). or maybe just opening it for reading will work. i
> don't know, i'm new to this bit of plan 9 & i haven't slept.
>
In sysopen, there is a call to namec:
/sys/src/9/port/sysfile.c:272
c = namec((char*)arg[0], Aopen, arg[1], 0);
Namec would return an error when called to open a directory with
execute permissions:
/sys/src/9/port/chan.c:1453,1454
if(amode == Aopen && (omode&3) == OEXEC && (c->qid.type))
error("cannot exec directory");
But I'm not sure if this is where the problem actually is, as I haven't seen
the 'cannot exec directory' message when running 'test -x dir' in
acid:
cpu% test -x ch7
cpu% echo $status
test 528: false
cpu% acid -l truss /bin/test
/bin/test:386 plan 9 executable
/sys/lib/acid/port
/sys/lib/acid/386
/sys/lib/acid/truss
acid: progargs = "-x ch7"
acid: new()
acid: truss()
open("ch7", 3)
return value: -1
open("#c/pid", 0)
return value: 3
pread(3, 0xdfffef08, 20, 4294967295)
return value: 12
data: "533 "
close(3)
return value: 0
533: breakpoint _exits+0x5 INTB $0x40
--
9fans: 9fans
Permalink:
https://9fans.topicbox.com/groups/9fans/Tdd7a9b1b32d01f54-Mb30227ca46f50cf45e98546c
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] `test -x` returns wrong results for directories
On Fri, Jun 5, 2020, at 8:22 PM, Richard Miller wrote: > Looks to me like access(2) is not doing the right thing for directory > execute (=search) permission. thanks for the tip. access is a very simple function. it doesn't do the right thing, but there's a reason: BUGS Since file permissions are checked by the server and group information is not known to the client, access must open the file to check permissions. (It calls stat(2) to check sim- ple existence.) it's open() which is failing. i suppose it should. if the open fails, maybe access should stat the file, and if it's a directory, try dirread(2). or maybe just opening it for reading will work. i don't know, i'm new to this bit of plan 9 & i haven't slept. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tdd7a9b1b32d01f54-M6c82b233d9b0cabf21ca7512 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] `test -x` returns wrong results for directories
Looks to me like access(2) is not doing the right thing for directory execute (=search) permission. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tdd7a9b1b32d01f54-M4da73ba68bd93f0827b0a15c Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
[9fans] `test -x` returns wrong results for directories
in rc-httpd, i rely on `test -x` to check if a directory is searchable. this
works in plan9port, 9base, inferno (with root from host fs), gnu coreutils, and
freebsd. it doesn't work in 9front, nor in labs plan 9. (the labs version
tested was a live-cd from 2010.)
term% test -x static ; echo $status
test 13436: false
term% ls -ld static
d-rwxrwxr-x M 24 ethan adm 0 Mar 15 14:58 static
term% man 1 test | grep -- -x
-x fileTrue if the file exists and has execute permis-
term%
the word 'wrong' in the subject may be a little strong, but there doesn't seem
to be an alternative test for searchable directories other than mucking about
with ls -l | sed or awk. test(1) has nothing to say on the matter.
for anyone using rc-httpd, the intended logic in rc-httpd/handlers/dir-index is
this:
if(! test -r $full_path -a -x $full_path) {
a suitable workaround is to remove ` -a -x $full_path`.
9front's version of rc-http has a workaround which may break when test is fixed.
/rc/bin/rc-httpd/handlers/dir-index:/-x
if(! test -r $full_path -x $full_path){
in plan 9 and gnu coreutils, this effectively replaces the logical and (-a)
with a logical or. freebsd reports an error, 'unexpected operator'.
--
9fans: 9fans
Permalink:
https://9fans.topicbox.com/groups/9fans/Tdd7a9b1b32d01f54-M4c8942fa39b91446ff4eb885
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] test(1) support for string length (-l) in p9p?
On Tue, Apr 10, 2018 at 09:28:42AM +0200, dexen deVries wrote: > the man page of test(1) mentions "-l string" as string length operator > for -eq, -gt, etc. > but there seems to be nothing in the plan9port's src/cmd/test.c, nor > in 9p.io/sources/cmd/test.c > > is there any implementation of this floating around? > Sure, in the research unix releases (e.g. [1]). No idea why it got dropped en route to today. Further: unknown why someone cared enough to drop the feature but not enough to fix the man page. khm 1 - https://raw.githubusercontent.com/dspinellis/unix-history-repo/Research-V7-Snapshot-Development/usr/src/cmd/test.c
[9fans] test(1) support for string length (-l) in p9p?
the man page of test(1) mentions "-l string" as string length operator for -eq, -gt, etc. but there seems to be nothing in the plan9port's src/cmd/test.c, nor in 9p.io/sources/cmd/test.c is there any implementation of this floating around?
[9fans] Test, please ignore
Test
[9fans] test
test
Re: [9fans] test
test number two :) 2015-05-18 7:46 GMT+03:00 mve...@mveety.com: Seems to work! -- Veety -- С наилучшими пожеланиями Жилкин Сергей With best regards Zhilkin Sergey
[9fans] test
test
Re: [9fans] test
Seems to work! -- Veety
Re: [9fans] test
lol... you shall have the 45 dollars by sundown, they say... On Wed, Apr 22, 2015 at 7:26 PM, Benjamin Huntsman bhunts...@mail2.cu-portland.edu wrote: Nice! From: 9fans-boun...@9fans.net [9fans-boun...@9fans.net] on behalf of Skip Tavakkolian [skip.tavakkol...@gmail.com] Sent: Wednesday, April 22, 2015 11:24 AM To: Fans of the OS Plan 9 from Bell Labs Subject: Re: [9fans] test a kernel may not work, due to unknown trap lack of wifi drivers and other such crap don't feel flaccid, fire up acid debug it yourself, and spare us the yap On Wed, Apr 22, 2015 at 11:03 AM Conor Williams conor.willi...@gmail.com mailto:conor.willi...@gmail.com wrote: the kernel does not work in an internet cafe what shall i do about the internet cafe ignore the kernel ignore the kernel ignore the kernel . . . ad infinium... On Mon, Apr 20, 2015 at 2:16 AM, Shane Morris edgecombe...@gmail.com mailto:edgecombe...@gmail.com wrote: Love the limerick! =P On Mon, Apr 20, 2015 at 11:08 AM, Skip Tavakkolian 9...@9netics.com mailto:9...@9netics.com wrote: please ignore... there was once a mascot named glenda for an operating system that's kinda splenda until, that is, a bunch of kids ripped off its front fenda
Re: [9fans] test
the kernel does not work in an internet cafe what shall i do about the internet cafe ignore the kernel ignore the kernel ignore the kernel . . . ad infinium... On Mon, Apr 20, 2015 at 2:16 AM, Shane Morris edgecombe...@gmail.com wrote: Love the limerick! =P On Mon, Apr 20, 2015 at 11:08 AM, Skip Tavakkolian 9...@9netics.com wrote: please ignore... there was once a mascot named glenda for an operating system that's kinda splenda until, that is, a bunch of kids ripped off its front fenda
Re: [9fans] test
a kernel may not work, due to unknown trap lack of wifi drivers and other such crap don't feel flaccid, fire up acid debug it yourself, and spare us the yap On Wed, Apr 22, 2015 at 11:03 AM Conor Williams conor.willi...@gmail.com wrote: the kernel does not work in an internet cafe what shall i do about the internet cafe ignore the kernel ignore the kernel ignore the kernel . . . ad infinium... On Mon, Apr 20, 2015 at 2:16 AM, Shane Morris edgecombe...@gmail.com wrote: Love the limerick! =P On Mon, Apr 20, 2015 at 11:08 AM, Skip Tavakkolian 9...@9netics.com wrote: please ignore... there was once a mascot named glenda for an operating system that's kinda splenda until, that is, a bunch of kids ripped off its front fenda
Re: [9fans] test
Love the limerick! =P On Mon, Apr 20, 2015 at 11:08 AM, Skip Tavakkolian 9...@9netics.com wrote: please ignore... there was once a mascot named glenda for an operating system that's kinda splenda until, that is, a bunch of kids ripped off its front fenda
[9fans] test
please ignore... there was once a mascot named glenda for an operating system that's kinda splenda until, that is, a bunch of kids ripped off its front fenda
[9fans] test
testing... -- cinap
Re: [9fans] test
On Nov 12, 2013, at 2:20, cinap_len...@felloff.net wrote: testing... -- cinap Works.
Re: [9fans] test(1) -older bug?
its /n/sources/patch/testolder, also leaks dir in the case: if(rel) n = time(0) - n; if(n 0) return 0; - HERE r = dir-mtime n; free(dir); return r; And the consequences of not freeing a few bytes of memory, in a command which will exit a few microseconds later, would be ... ?
Re: [9fans] test(1) -older bug?
On Jun 3, 2013 6:49 AM, Richard Miller 9f...@hamnavoe.com wrote: And the consequences of not freeing a few bytes of memory, in a command which will exit a few microseconds later, would be ... ? bad taste.
Re: [9fans] test(1) -older bug?
bad taste. I agree - better style is to free memory always, or never. But the choice might not be as obvious as one first thinks.
Re: [9fans] test(1) -older bug?
Richard Miller 9f...@hamnavoe.com wrote: And the consequences of not freeing a few bytes of memory, in a command which will exit a few microseconds later, would be ... ? The Code Correctness Police come and collect you and force you to program on Windows... ducks :-) Arnold
Re: [9fans] test(1) -older bug?
On Mon Jun 3 08:00:20 EDT 2013, arn...@skeeve.com wrote: Richard Miller 9f...@hamnavoe.com wrote: And the consequences of not freeing a few bytes of memory, in a command which will exit a few microseconds later, would be ... ? The Code Correctness Police come and collect you and force you to program on Windows... ducks excellent points. there is no consequence. but conversely, there is no penalty for free'ing the memory either. given that, i prefer free'ing the memory to be consistent with the rest of the source, and accept cinap's bug as a bug. of course you can say needless consistency is the hobgoblin of little minds... :-) - erik
Re: [9fans] test(1) -older bug?
its /n/sources/patch/testolder, also leaks dir in the case: if(rel) n = time(0) - n; if(n 0) return 0; - HERE r = dir-mtime n; free(dir); return r; -- cinap
Re: [9fans] test(1) -older bug?
On Sun Jun 2 17:31:05 EDT 2013, cinap_len...@gmx.de wrote: its /n/sources/patch/testolder, also leaks dir in the case: if(rel) n = time(0) - n; if(n 0) return 0; - HERE r = dir-mtime n; free(dir); return r; thanks. i appreciate the catch. [sources] applied patch: /n/atom/patch/applied/testolder1 email quans...@quanstro.net readme fix memory leak pointed out by cinap removed files /sys/src/cmd/test.c test.c /sys/src/cmd/test.c test.c test.c.orig:373,380 - test.c:373,381 if(rel) n = time(0) - n; if(n 0) - return 0; - r = dir-mtime n; + r = 0; + else + r = dir-mtime n; free(dir); return r; -- merge...backup...copy... cpfile test.c /n/dist/sys/src/cmd/test.c done
[9fans] test(1) -older bug?
Hello, How do you think? I think test is buggy in older operation. the test is from 9front. I have not tried bell-labs test. term% ls -l --rw-rw-r-- M 149 arisawa arisawa 3277 Apr 9 23:11 x --rw-rw-r-- M 149 arisawa arisawa 4555 Apr 9 23:12 y term% mtime x 1365516710 x term% mtime y 1365516741 y term% if(test x -ot y) echo OK OK term% if(test x -older 1365516741) echo OK term% if(test x -older 1365516700) echo OK term% term% date -n 1370119926 term% dc 1370119926 1365516710 - p 4603216 term% if(test x -older 4603216) echo OK OK term% if(test x -older 4703216) echo OK term% term% man test f -older t True if file f is older than (modified before) time t. If t is a integer followed by the letters y(years), M(months), d(days), h(hours), m(minutes), or s(seconds), it represents current time minus the specified time. If there is no letter, it represents seconds since epoch. You can also concatenate mixed units. For example, 3d12h means three days and twelve hours ago. Kenji Arisawa
Re: [9fans] test(1) -older bug?
yup. i think it's a bug: /n/sources/patch/older /n/atom/patch/older - erik
[9fans] Test suite for 9P
Hi, I'd like to implement a library for 9P (just for the sake of it :)) and I wonder if there are any test suites that'd help to make sure that the library works as expected. -- Misha
Re: [9fans] test -w on directory
kb=4096 say what!? fittingly, it's unused. i'd suppose it was probably going to reduce the buffer size on a wirelessly-connected ipaq
[9fans] test -w on directory
yesterday. anth_x discovered that test -w on directory always returns false even tho the directory is writable. test works by calling access(AWRITE) on the file which tries a open(OWRITE) on the directory. this always fails because you can't open directory for writing. some rc scripts seem to assume that test -w should work on directories. examples are /rc/bin/lp which tests for /tmp being writable. another is /rc/bin/juke that tests on /mnt/juke. i dont know if there are other programs that use access() to test on directory writability. (i guess not) its hard for access() to figure out effective directory writability except by trying to create a file in the dir (very bad idea). (is access() allowed to return false positives but no false negatives?) its not clear to me from the manpage that access() is expected to work on directories. access bug? is test at fault here? did it work once? are these rc scripts that use test -w on directories bogus? suggestions? :) -- cinap
Re: [9fans] test -w on directory
some rc scripts seem to assume that test -w should work on directories. examples are /rc/bin/lp which tests for /tmp being writable. another is /rc/bin/juke that tests on /mnt/juke. in both cases, the test returning the wrong result won't easily be noticed. lp just mounts somthing else on /tmp on failure, and juke restarts/remounts whatever. i'm not sure anyone has noticed. by the way, i notice juke has this gem: kb=4096 say what!? fittingly, it's unused. - erik
[9fans] test
can't receive mail from 9fans anymore. but can i still send? -- cinap
Re: [9fans] test
On Apr 16, 2012 2:48 PM, cinap_len...@gmx.de wrote: can't receive mail from 9fans anymore. but can i still send? -- cinap Yes. -- Veety
Re: [9fans] test
got it clear. -- iphone kbd. excuse typos :) On Apr 16, 2012, at 6:46 PM, cinap_len...@gmx.de wrote: can't receive mail from 9fans anymore. but can i still send? -- cinap
Re: [9fans] test
Obvious solution, switch to reading comp.os.plan9 and sending replies to the list :-) On Apr 16, 2012 11:48 AM, cinap_len...@gmx.de wrote: can't receive mail from 9fans anymore. but can i still send? -- cinap
Re: [9fans] test command
Hello, On 2008/09/11, at 11:38, Russ Cox wrote: there are certainly better ways to do this, but this works: as does /bin/mtime. I didn't know this command. thanks russ and erik. Kenji Arisawa
[9fans] test command
Hello, test command of plan 9 has a operator older, the usage is: test f -older t where f is a file and t is a time. however the command does not have newer operator. why? Kenji Arisawa
Re: [9fans] test command
On Wed, Sep 10, 2008 at 3:19 AM, Kenji Arisawa [EMAIL PROTECTED] wrote: Hello, test command of plan 9 has a operator older, the usage is: test f -older t where f is a file and t is a time. however the command does not have newer operator. why? If a b, and you want to know if b a, can't you just do a b? ron
Re: [9fans] test command
a b = !(a b) + (a = b) On Wed, Sep 10, 2008 at 3:19 AM, Kenji Arisawa [EMAIL PROTECTED] wrote: Hello, test command of plan 9 has a operator older, the usage is: test f -older t where f is a file and t is a time. however the command does not have newer operator. why? If a b, and you want to know if b a, can't you just do a b? ron -- Rodolfo García AKA kix http://www.kix.es/ EA4ERH (@IN80ER)
Re: [9fans] test command
On Wed, Sep 10, 2008 at 6:38 AM, ron minnich [EMAIL PROTECTED] wrote: On Wed, Sep 10, 2008 at 3:19 AM, Kenji Arisawa [EMAIL PROTECTED] wrote: Hello, test command of plan 9 has a operator older, the usage is: test f -older t where f is a file and t is a time. however the command does not have newer operator. why? If a b, and you want to know if b a, can't you just do a b? ron Yeah with and ! you can build anything you want :-) Hence why many C++ STL comparisons just require you to make a functor for less. Dave
Re: [9fans] test command
Maybe I'm confused, but what Kenji said is that: test command of plan 9 has a operator older, the usage is: test f -older t where f is a file and t is a time. If f is a file ant t is a *time*, you can't do test t -older f Juan
Re: [9fans] test command
On Wed, Sep 10, 2008 at 5:27 PM, Juan Céspedes [EMAIL PROTECTED] wrote: Maybe I'm confused, but what Kenji said is that: test command of plan 9 has a operator older, the usage is: test f -older t where f is a file and t is a time. If f is a file ant t is a *time*, you can't do test t -older f yes, but !older is the same as younger or equal. !(test f -older t) would be the same (equality notwithstanding) as test f -younger t But then there is = and != for strings (for example), so this argument is thin :-). -- - curiosity sKilled the cat
Re: [9fans] test command
But then there is = and != for strings (for example), so this argument
is thin :-).
if we can easily get modified time of a file in the format of UNIX time,
where easily means in the set of plan 9 commands.
there are certainly better ways to do this, but this works:
- erik
#!/bin/rc
rfork e
p='
$1 == mtime: {
gsub([()], , $8)
print $8
}'
for(i){
syscall -s fstat 0 buf 1024$i[2=1] |
awk $p
}
