[9fans] aes_decrypt() in /sys/src/9/ip/esp.c
Has anyone seen this function? Its absence inhibits successful compilation of the pcdisk kernel. I'm slowly searching sources to see if I'm missing something and I'll remove esp as a feature for my purposes, but I trust that the problem has a simple resolution. ++L
Re: [9fans] aes_decrypt() in /sys/src/9/ip/esp.c
Has anyone seen this function? /sys/src/libsec/port/aes.c:1478
Re: [9fans] clarification on man 9p
On Sat, Oct 3, 2009 at 8:29 AM, Russ Cox r...@swtch.com wrote: In general, the File interface is appropriate for maintaining arbitrary file trees (as in ramfs). The File interface is best avoided when the tree structure is easily generated as necessary; this is true when the tree is highly structured (as in cdfs and nntpfs) or is maintained elsewhere. Is this referring to avoiding the usage of createfile and friends in 9pfile.h for highly structured trees? Yes. You can look at the named examples to see the alternative. My experience has been, well, what it says in the man page: the File interface was an interesting idea but is rarely useful. I understand, what confused me was that ramfs is not using File/createfile. So even though ramfs could have taken advantage of the createfile tools it didn't. why? The only fileserver that I found that was actually using createfile is rdbfs. regards fernan -- http://www.fernski.com
Re: [9fans] Plan 9 Xen -- Follow up on previous 9fans topic
The kernel did not compile against the most recent sources. I've fixed this so it compiles again with current kernel source. Haven't tried booting it on anything, though.
Re: [9fans] clarification on man 9p
There is a version that is. Its source is with the library. - Curiosity sKilled the cat G. On Oct 3, 2009, at 11:26 AM, Fernan Bolando fernanbola...@mailc.net wrote: On Sat, Oct 3, 2009 at 8:29 AM, Russ Cox r...@swtch.com wrote: In general, the File interface is appropriate for maintaining arbitrary file trees (as in ramfs). The File interface is best avoided when the tree structure is easily generated as necessary; this is true when the tree is highly structured (as in cdfs and nntpfs) or is maintained elsewhere. Is this referring to avoiding the usage of createfile and friends in 9pfile.h for highly structured trees? Yes. You can look at the named examples to see the alternative. My experience has been, well, what it says in the man page: the File interface was an interesting idea but is rarely useful. I understand, what confused me was that ramfs is not using File/ createfile. So even though ramfs could have taken advantage of the createfile tools it didn't. why? The only fileserver that I found that was actually using createfile is rdbfs. regards fernan -- http://www.fernski.com
Re: [9fans] inferno from hg does not build out of the box
Let's fix this now. Here is a one-line fix, which is simpler and cleaner than a multi-empty-file commit. My old fix mkdir -p `lib/emptydirs` is a bashism I think, I've reworded it: xargs mkdir -p lib/emptydirs That will suffice to fix the problem for unix users at least. xargs might not be present, we can do it with only the shell; this might be best: while read d; do mkdir -p $d; done lib/emptydirs Could you please add this fix to makemk.sh? I put it at the end of the following stanza which seems appropriate (patch below). # make sure we start off clean echo removing old libraries and binaries rm -f $PLAT/lib/*.a $PLAT/bin/* rm -f utils/cc/y.tab.? while read d; do mkdir -p $d; done lib/emptydirs A general fix for hg/git/etc would be to keep a list of all directories in the RCS as a file .hg-dirs or .hg/dirs (but forbidden), and a post-update to create/remove them as needed. Is it best to talk about inferno on 9fans or should I use/Cc inferno-list? thanks, Sam --- makemk.sh.orig 2009-10-04 00:55:37.0 +1000 +++ makemk.sh 2009-10-04 00:56:10.0 +1000 @@ -42,6 +42,7 @@ echo removing old libraries and binaries rm -f $PLAT/lib/*.a $PLAT/bin/* rm -f utils/cc/y.tab.? +while read d; do mkdir -p $d; done lib/emptydirs # libregexp cd $ROOT/utils/libregexp || error cannot find libregexp directory
[9fans] mishandling empty lists - let's fix it
hi, I wanted to have a whinge about one fault I find in unix: commands such as cat, grep etc. do not handle an empty argument list correctly. For example, cat should output nothing and exit - concatenating 0 files. Instead it copies stdin to stdout, which is inconsistent. This problem still exists in plan 9. Copying stdin should be coded as: cat - Such syntax would provide useful extra capability: find -type d | cat lib/emptydirs - | mail 9fans@9fans.net Although this bug is not annoying for command-line work, consider a script that processes all .c files to be found using cat or grep: find -name '*.c' | xargs cat | cc - # this clever cc can handle it :) This program works fine until there are no .c files to be found, in that case it hangs, waiting for one on stdin! This is a hazard to shell scripters, and a potential source of security holes. It's worse than cat -v. Another example: 8c echo 1 should compile 0 files to give an empty object file, and echo 1. Is there any chance we could fix these things in plan 9/inferno? I feel that freedom from past mistakes is a key principle of plan 9. If people support this change, I would be keen to work on it. thanks! Sam (I noticed the pike language has a similar bug, `+(1,2,3) - 6 but `+() - error! `+() should be 0 and `*() should be 1, of course.) I don't think such bugs exist in Lisp :)
Re: [9fans] mishandling empty lists - let's fix it
cat * /dev/null is the recommended solution. -rob
Re: [9fans] mishandling empty lists - let's fix it
On Sat, Oct 03, 2009 at 10:01:09AM -0700, Rob Pike wrote: cat * /dev/null is the recommended solution. Thanks Rob, That works with cat, but it won't work with chmod, grep -L, ls, find, file and many others. I think all of the unix and plan 9 utilities that deal with a variable number of files have this problem. Does anyone agree with me that it needs fixing? Sam
Re: [9fans] mishandling empty lists - let's fix it
On Sun, 04 Oct 2009 03:03:27 +1100 Sam Watkins s...@nipl.net wrote: find -name '*.c' | xargs cat | cc - # this clever cc can handle it :) This program works fine until there are no .c files to be found, in that case it hangs, waiting for one on stdin! This is a hazard to shell scripters, and a potential source of security holes. Your example doesn't hang (and if it does, your xargs is broken). You are thinking of something like this: $ echo 'cat $*' foo.sh $ sh foo.sh This is not elegant but a reasonable tradeoff. A common use of many tools is in a pipeline and having to type - every time can get annoying. To fix this you may think of changing your shell to append /dev/null if a command is given no arguments but that will fail in cases like `cat -v'. In unix it is upto each command to interprets its arguments and a shell can not assume anything about command arguments.
Re: [9fans] mishandling empty lists - let's fix it
Does anyone agree with me that it needs fixing? I don't. I also think that even if it were a problem the usage is far too ingrained to be fixable. -rob
Re: [9fans] mishandling empty lists - let's fix it
Does anyone agree with me that it needs fixing? I don't. I also think that even if it were a problem the usage is far too ingrained to be fixable. Nor do I. Having the no-argument case be filter behavior (stdin/stdout) is the most elegant, consistent, and predictable of the options I've seen. BLS
Re: [9fans] mishandling empty lists - let's fix it
Nor do I. Having the no-argument case be filter behavior (stdin/stdout) is the most elegant, consistent, and predictable of the options I've seen. Yeah, I always found the lone - very ugly! If you do a fix you could also add --outputfile in order to improve the readability :D
Re: [9fans] mishandling empty lists - let's fix it
Does anyone agree with me that it needs fixing? sorry, I don't agree that it is broken so I don't thing it need fixing. It does occasionally annoy me that tr(1) will not take a file as an argument but again, changing that would have implications too wide to make it worthwhile; I try to think of it as OS patina. -Steve
Re: [9fans] mishandling empty lists - let's fix it
I don't see how this can be fixed in unix without breaking umpteen million shell scripts. By creating new commands with distinct new names. ++L
