Support relative paths (with -v/--volume and -w/--workdir)

[jakirkham]

It would be nice, particularly on the host side, if relative paths could be used here. Supporting this might be as simple as converting them to absolute paths once the arguments are parsed before continuing. On the container side, if there is a way to inspect the current workdir, this would, ideally, be simple, as well.

[GordonTheTurtle]

Hi!

Please read this important information about creating issues.

If you are reporting a new issue, make sure that we do not have any duplicates already open. You can ensure this by searching the issue list for this repository. If there is a duplicate, please close your issue and add a comment to the existing issue instead.

If you suspect your issue is a bug, please edit your issue description to include the BUG REPORT INFORMATION shown below. If you fail to provide this information within 7 days, we cannot debug your issue and will close it. We will, however, reopen it if you later provide the information.

This is an automated, informational response.

Thank you.

For more information about reporting issues, see https://github.com/docker/docker/blob/master/CONTRIBUTING.md#reporting-other-issues

---

BUG REPORT INFORMATION

Use the commands below to provide key information from your environment:

docker version:
docker info:
uname -a:

Provide additional environment details (AWS, VirtualBox, physical, etc.):

List the steps to reproduce the issue:
1.
2.
3.

Describe the results you received:

Describe the results you expected:

Provide additional info you think is important:

----------END REPORT ---------

#ENEEDMOREINFO

[phemmer]

It would be nice, particularly on the host side, if relative paths could be used here.

Relative to what?

[jakirkham]

On the host side? Relative to the current working directory.
On the guest side? Relative to whatever WORKDIR or what the -w/--workdir are set to. If unset, this would just be /.

[phemmer]

On the host side? Relative to the current working directory.

Using the current working directory is impossible. The docker client doesn't necessarily reside on the same host as the docker daemon.

[jakirkham]

I don't know that I agree with your pessimism. The client can convert the host side path to absolute paths before passing them through. I'm assuming you are referring to the boot2docker case.

[phemmer]

No it can't.
If I'm on my client in /home/phemmer, and I run docker run -v ./:/foo, but the docker host is remote, and /home/phemmer doesn't exist there, what will be mounted?

[jakirkham]

Again, assuming you are referring to boot2docker. It actually mirrors your paths into the VM. So, there will be /home/phemmer in the VM. For instance, on my Mac I can run boot2docker ssh and ls /Users/kirkhamj/ and see my home folder no problem. I am not sure how this case is handled with the Linux VM. In any event, I think you are missing my suggestion, which is with boot2docker cases the path be converted to an absolute path before calling docker within the VM. This will not be a problem as this already works now.

[phemmer]

I'm not referring to boot2docker.
The docker client operates via http calls. Thus the client filesystem does not have to look anything like the host's filesystem. boot2docker is popular yes, but it is not the only case where the client is remote to the host. Docker cannot support anything which relies upon the two to share a filesystem.

[thaJeztah]

Docker-compose currently does just this, but relative to the docker-compose.yml file. For docker, the general way to handle this, is docker run -v $(pwd)/foo:/bar ....

However, @phemmer is right that the file system on the host you're running the client on can have a completely different directory layout then the host the daemon runs on. For this reason, Docker will not assume anything (think, for example, of cases where the docker daemon runs somewhere in the cloud)

Boot2Docker is targeted at local development and shares the /Users/ directory with the Boot2Docker virtual machine using VirtualBox shares. Basically, this is just a "hack" to make it work as if the daemon is running on your local system. Trying to use anything outside the `/Users/’ directory will fail to work or, more accurately, result in empty mountpoints being created on the daemon's file system.

I understand your use case, and this would make it more convenient to work with when using Boot2Docker, but I think it should be closed for the above reasons.

So, I'm -1, but there may be others that think different

[cpuguy83]

Closing because this is just not really possible.
Again it's relative to what exactly.
If you want to use a relative path to your current working dir you can use $(pwd).