> Has anyone seen this function?
/sys/src/libsec/port/aes.c:1478
On Sat, Oct 3, 2009 at 8:29 AM, Russ Cox 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 structure
> 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.
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
wrote:
On Sat, Oct 3, 2009 at 8:29 AM, Russ Cox wrote:
"In general, the File interface is appropriate for maintaining
arbitrary file trees (as in ramfs)
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 `
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
cat * /dev/null
is the recommended solution.
-rob
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 f
On Sun, 04 Oct 2009 03:03:27 +1100 Sam Watkins 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
> 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
>> 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
On Sun, 04 Oct 2009 03:03:27 +1100 Sam Watkins wrote:
> find -name '*.c' | xargs cat | cc -
On Sat, Oct 03, 2009 at 11:46:16AM -0700, Bakul Shah wrote:
> Your example doesn't hang (and if it does, your xargs is broken).
hm sorry, I meant:
cat `find -name *.c` | cc -
> A common use of many t
> 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
> 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
> 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
I'm having an issue with replica on 9vx. I keep getting files like this:
d-2 tc staff4096 Oct 4 05:38 bibtex/
d-2 tc staff4096 Oct 4 05:38 bin/
strace shows this:
13293 mkdir("/mnt/sdb1/tc/plan9/9vx-0.12/sys/lib/texmf/bibtex/bst", 0)
= -1 EAC
16 matches
Mail list logo
