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
> 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
> /\
>
