Re: install(1) fails when reading from stdin
On Tue, Sep 26, 2017 at 02:59:30PM +, Alfred Morgan wrote: > Of course I can cat > a/b/myfile && chown me a/b/myfile && chgrp me > a/b/myfile && chmod 0440 a/b/myfile but I know there is a stock command > that fits the bill (install) but then I find to my disappointment that > install can't accept stdin. What a let down and it feels anti-unix to me. Please read the very last line of the DESCRIPTION section of install(1) and then use install(1) followed by cat(1). There's no point in adding features to install(1). Ciao, Kili
Re: Too many open files error on OpenBSD 5.4 amd64 and Polipo 1.0.4.1p6
[cc: and reply-to: ports, because I thinkg that's the better place for this problem] On Sun, Aug 10, 2014 at 11:02:38AM +0400, Denis Lapshin wrote: > After 24-48 hours of Polipo working all the HTTP proxy clients get "To many > open files" error. That's an error message produced by polipo? > Is there a bug? Probably, allthough I didn't run into any fd leaks. But I'm using polipo only at home, with a very small number of clients (three or four). > Restarting Polipo from /etc/rc.d/polipo solves the problem for about 24 > hours before the error appears again. Can you check with fstat(1) how many clients are connected and how many connections polipo has to the outside, right after the start, after a few hours, and after the fd exhaustion happens? Ciao Kili ps: polipo-1.0.4.1 is outdated, i'll test polipo-1.1.1 a little bit and send a diff to ports@ if everything works well.
Re: [PATCH][BUG] ksh / sh segfault
On Tue, Jan 31, 2012 at 01:10:28PM +0100, Otto Moerbeek wrote: > I could reproduce the bug, but I'm not 100% happy with your fix since > it just pushes the failure to a bigger number of vars. > > It's better to check for the case like below, > > -Otto > > Index: table.c > === > RCS file: /cvs/src/bin/ksh/table.c,v > retrieving revision 1.13 > diff -u -p -r1.13 table.c > --- table.c 17 Jan 2009 22:06:44 - 1.13 > +++ table.c 31 Jan 2012 12:07:20 - > @@ -108,7 +108,10 @@ ktenter(struct table *tp, const char *n, > } > > if (tp->nfree <= 0) { /* too full */ > - texpand(tp, 2*tp->size); > + if (tp->size <= SHRT_MAX/2) > + texpand(tp, 2*tp->size); > + else > + internal_errorf(1, "too many vars"); > goto Search; > } Regardless of the other problem filling up the table, i think that this should be comitted. FWIW, the problem doesn't apply to the ffmpeg we currently have in ports. Ciao, Kili