Date: Thu, 14 Nov 2002 19:32:46 -0500 (EST) From: Robert Watson <rwatson@FreeBSD.org> To: "Bruce A. Mah" <bmah@FreeBSD.org> Cc: John Baldwin <jhb@FreeBSD.org>, cvs-all@FreeBSD.org, cvs-committers@FreeBSD.org Subject: Re: cvs commit: src/usr.sbin/pkg_install/lib file.c Message-ID: <Pine.NEB.3.96L.1021114193126.6671D-100000@fledge.watson.org> In-Reply-To: <200211150024.gAF0Oo3A066723@intruder.bmah.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 14 Nov 2002, Bruce A. Mah wrote: > > Ugh, can't we look at the file header and figure out based on that > > instead? > > I don't like this either, but real autodetection is harder than I wanted > to tackle. My goal was to get a snapshot build that can install > packages. > > After having hacked on unpack() for a while, it's harder than I first > thought. Looking at the first byte of the file is enough to distinguish > the two...if it's '\037', it's gzip; 'B' means bzip2, according to the > source code for file(1). > > You need to peek at the first byte of the file and then put the byte > back (remember this is for a package on stdin). I tried fgetc()/ > ungetc()) for this. I suspect that the character that I put back > doesn't get read by the forked-off gzip or bzip process. Yeah, ungetc() acts on the FILE* libc buffered streams, which means that the character has been read out of the file descriptor and into per-process memory buffering, so is no longer available to other processes. In practice, I think you end up having to create a new pipe and manually buffer the data from the source to gzip/bzip2. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Network Associates Laboratories To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1021114193126.6671D-100000>