Re: [rfc] leverage -x/-X tar call to pass more tar options
Hi!
On Sun, 2010-07-04 at 00:20:02 +0200, Pierre Habouzit wrote:
> I'm in the process of moving apt-listchanges to C, slowly, and the
> attached patch would make it really easier for me to work with dpkg-deb.
Just OOC, why C and not C++ being it supposedly part of the apt
namespace?
Ok, I've checked now the source and I guess the answer might be,
because it does not really depend on anything apt related (except
for the invokation hook protocol to retrieve the package and version
list). If we extended the dpkg invoke hooks, apt-listchanges could
become something lower level, that could be hooked directly into dpkg.
> The point is that doing chained pipes is pretty annoying from C
> (especially if you want to use parallelism in the process), plus it kind
> of make sense for many kind of operations where you don't need
> --fsys-tarfile anymore: e.g. extracting a single file can be done with:
Well, as surely it might be slightly annoying, I don't think it implies
that much code. It's oubviously easier and more comfortable to be able
to extract specific files to extract, it's also more performant than
filtering them out after the fact. So I agree it's a nice feature to
have, but ...
> dpkg-deb -x file.deb some-dir ./path/to/file/to/extract
>
> What I do is that additionnal arguments passed after the "directory"
> argument of -x and -X are passed straight to tar.
... definitely not by allowing any option to be forwarded to tar,
which would make the fact that we are internally using the tar binary
an exported interface. And in case we wanted to switch to a pure C
implementation we'd have to either break or support parsing random tar
options!
What I can see as acceptable would be to only allow additional
optional filenames after the directory argument. But then I guess that
might not be enough, and we might need to support wildcards too. So
the tar call would end up being something like:
if $tar_files
tar xpf - --wildcards -- $tar_files
else
tar xpf -
> >From ba0dd1312e16e5a9ad266549b0caa8d6fa9186fd Mon Sep 17 00:00:00 2001
> From: Pierre Habouzit <madcoder@debian.org>
> Date: Sat, 3 Jul 2010 09:04:26 +0200
> Subject: [PATCH] dpkg-deb: --[v]extract can take tar options.
>
> Allow --extract/vextract to take additionnal arguments as arguments to the
> underlying tar call. This leverages the underlying tar invocation.
> Avoiding the need for a pipe of `dpkg-deb --fsys-tarfile` into tar(1).
>
> This eases the call of dpkg-deb from e.g. C.
> diff --git a/dpkg-deb/extract.c b/dpkg-deb/extract.c
> index e5e1f9c..914224b 100644
> --- a/dpkg-deb/extract.c
> +++ b/dpkg-deb/extract.c
> @@ -315,7 +316,10 @@ void extracthalf(const char *debar, const char *directory,
> if (taroption) {
> c3 = subproc_fork();
> if (!c3) {
> + const char **targv, **arg;
> char buffer[30+2];
> + int i;
> +
> if (strlen(taroption) > 30)
> internerr("taroption is too long '%s'", taroption);
> strcpy(buffer, taroption);
> @@ -325,7 +329,17 @@ void extracthalf(const char *debar, const char *directory,
>
> unsetenv("TAR_OPTIONS");
>
> - execlp(TAR, "tar", buffer, "-", NULL);
> + for (i = 0; taropts && taropts[i]; i++);
> + arg = targv = m_malloc((5 + i + 1) * sizeof(targv[0]));
> + *arg++ = "tar";
> + *arg++ = buffer;
> + *arg++ = "-";
> + if (i) {
> + mempcpy(arg, taropts, i * sizeof(taropts[0]));
> + arg += i;
> + }
> + *arg++ = NULL;
> + execvp(TAR, (char *const *)targv);
> ohshite(_("failed to exec tar"));
> }
> close(p2[0]);
Here you should just use the command module.
thanks,
guillem
Reply to: