On Sun, Nov 24, 2013 at 7:29 PM, sven falempin <sven.falem...@gmail.com> wrote: > > > On Sun, Nov 24, 2013 at 5:57 PM, Andres Perera <andre...@zoho.com> wrote: >> >> >> >> >> On Sun, Nov 24, 2013 at 12:11 PM, sven falempin <sven.falem...@gmail.com> >> wrote: >>> >>> On Sat, Nov 23, 2013 at 5:47 PM, Theo de Raadt >>> <dera...@cvs.openbsd.org>wrote: >>> >>> > > On 2013/11/23 14:39, sven falempin wrote: >>> > > > Hello, >>> > > > >>> > > > Another point of vue : >>> > > > Because curl is in base, what does ftp client add to the system ? >>> > > >>> > > ftp(1) is not without problems (bad ssl support, semi-broken proxy >>> > > support, difficult code) but it has one major advantage: the small >>> > > version used on ramdisks is quite small, something like 80k. >>> > > >>> > > cURL is not in base, but even if it was, it looks to be much too >>> > > big for the ramdisks. >>> > >>> > As a note to anyone skilled... take the above issues as a challenge. >>> > If you can improve those problems in ftp(1), we'd love it. But it >>> > must remain a fairly small program. >>> > >>> >>> Proposed (incomplete) behavior : >>> >>> EBADF => fatal >>> EFBIG, EIO, EPIPE => warn + quit this file ( but EPIPE => wait for >>> someone >>> to open the pipe ? or warn + quit this file ) >> >> >> $ cat /dev/zero | cat >/dev/null & >> [1] 15546 28664 >> $ kill -INT 28664 >> $ jobs >> [1] + Broken pipe cat /dev/zero | >> Interrupt cat > /dev/null >> >> here, 15546 exits because of EPIPE during write >> >> it does not warn about anything >> >> 28664 could've been signaled in any fashion, INT is used to highlight it >> might be interactive use >> >> why should a user interrupt end up as a warning? big friggen deal just >> exit the program > > > because the job is unfinished, moreover you just kill one of two programs > > I do not think your case is relevant.
the process getting EPIPE doesn't know that the process reading was killed it doesn't know anything other than EPIPE why woud it spin infinately waiting for the fd to open again, as you suggested? or even print a warning? > >> >> >>> >>> ENOSPC, EDQUOT => warn + quit this file, or warn + sleep (hope someone >>> rm >>> some stuff) >>> EINTR => info + retry ? how many retry ? or for how long ? >>> EFAULT => call the martian + fatal >>> >>> >>> EAGAIN => call poll and retry ? some fs can do that right ? >>> >>> Network related => ignore (fout is not a socket) >>> But this one >>> << >>> [EIO] The process is a member of a background process >>> attempting to write to its controlling terminal, >>> TOSTOP is set on the terminal, the process isn't >>> ignoring the SIGTTOUT signal and the thread isn't >>> blocking the SIGTTOUT signal, and either the >>> process >>> was created with >>> >>> vfork(2)<http://www.openbsd.org/cgi-bin/man.cgi?query=vfork&sektion=2&arch=i386&apropos=0&manpath=OpenBSD+Current>and >>> >>> hasn't successfully >>> executed one of the exec functions or the process >>> group is orphaned. >>> >>> >> >>> Yes this one would require skillz >>> of fatal("I dont get it, can you please use your ftp client like anyone >>> else :-)"); >>> >>> >>> -- >>> >>> --------------------------------------------------------------------------------------------------------------------- >>> () ascii ribbon campaign - against html e-mail >>> /\ >> >> > > > > -- > --------------------------------------------------------------------------------------------------------------------- > () ascii ribbon campaign - against html e-mail > /\
