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
Has anyone seen this function?
/sys/src/libsec/port/aes.c:1478
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
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 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
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
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
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
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
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
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
15 matches
Mail list logo
