add CTRL+e for extracting current focused file

[kaedwen]

Added a way to extract the current focused item in the tree view. This is far from optimal and we can start discussing on it. https://github.com/wagoodman/dive/issues/224

[TheRealGramdalf]

This could use docker create and docker cp which would be much more efficient: https://unix.stackexchange.com/questions/331645/extract-file-from-docker-image

[miskr-instructure]

This could use docker create and docker cp which would be much more efficient:

• docker cp requires tar to be installed in the image which makes that solution worse.
• docker cp also requires the container to be running, so the entrypoint would need to be overwritten with a program that keeps running, this also requires specific binaries (eg. sleep/tail) to be present
• it would be difficult to ensure that the container is deleted in every case (dive can get killed/terminated)
• for small images, or if the file is early in the tar stream, the PR's solution is probably more efficient that waiting for docker to spin up a sandbox and run a process in it.

[TheRealGramdalf]

• docker cp requires tar to be installed in the image which makes that solution worse.

• I wasn't able to find anything that would indicate this - as far as I'm aware it just finds the file in the relevant /var/lib/docker/overlay2/* directory from the host.

• docker cp also requires the container to be running, so the entrypoint would need to be overwritten with a program that keeps running, this also requires specific binaries (eg. sleep/tail) to be present

• The answer I linked says otherwise: "According to the docker create documentation, this doesn't run the container:"

The docker create command creates a writeable container layer over the specified image and prepares it for running the specified command. The container ID is then printed to STDOUT. This is similar to docker run -d except the container is never started. You can then use the docker start <container_id> command to start the container at any point.

• it would be difficult to ensure that the container is deleted in every case (dive can get killed/terminated)

• This is a fair point. I'm not sure how exactly you would get around this, but it really shouldn't be that bad - a docker prune would easily fix this. Worst case scenario make dive create containers with a specific label (like --label wagoodman.dive.temp), and then check for containers with that label on next run (and notify the user to remove them/remove them automatically)

• for small images, or if the file is early in the tar stream, the PR's solution is probably more efficient that waiting for docker to spin up a sandbox and run a process in it.

• True, it might be. Except for the process point, since doesn't need to spin up the sandbox.

The only other thing I can think of is copying a file from an intermediate layer (that has been changed in a following layer) - I'm not sure if you can do that with docker cp, it doesn't look like you can

[kaedwen]

Hey @TheRealGramdalf, I would say that @miskr-instructure is right with the docker cp had this problem (hence the idea of using Dive and using it to extract files)

Try this

• use a container FROM scratch, with just one file in it
• try docker cp with it, it will complain about not having cp, and if you have it in there (busybox or whatever), the next missing is tar

[miskr-instructure]

^ You may be able to solve those by readonly-mounting cp and tar from somewhere outside, but those have the dynamic library dependencies (unless they are busybox-based) which you'd also need to mount in, etc...

All the solutions to this are more complex than the PR's. The only other trick would be directly accessing docker's image repo in the filesystem instead of going through the daemon, which is too brittle.