Alright, first create a specific project directory for your docker image. For example:

mkdir /home/pi/Desktop/teasr/capturing

Copy your dockerfile and script in there and change the current context to this directory.

cp /home/pi/Desktop/teasr/capturing.py /home/pi/Desktop/teasr/dockerfile /home/pi/Desktop/teasr/capturing/

cd /home/pi/Desktop/teasr/capturing

This is for best practice, as the first thing the docker-engine does on build, is read the whole current context.

Next we'll take a look at your dockerfile. It should look something like this now:

FROM python:latest

WORKDIR /usr/local/bin

COPY capturing.py .

CMD ["capturing.py", "-OPTIONAL_FLAG"]

The next thing you need to do is build it with a smart name. Using dots is generally discouraged.

docker build -t pulkit/capturing:1.0 .

Next thing is to just run the image like you've done.

docker run -ti --name capturing pulkit/capturing:1.0

The script now get executed inside the container and will probably exit upon completion.

Edit after finding the problem that created the following error:

standard_init_linux.go:195: exec user process caused "exec format error"

There's a different architecture beneath raspberry pi's (ARM instead of x86_64), which COULD'VE BEEN the problem, but wasn't. If that would've been the problem, a switch of the parent image to FROM armhf/python would've been enough.

Source

BUT! The error kept occurring.

So the solution to this problem is a simple missing Sha-Bang on top of the python script. The first line in the script needs to be #!/usr/bin/env python and that should solve the problem.

Source

Syntactically, CMD can have two forms. The exec form must be a JSON array, with individual words double-quoted; you are responsible for breaking the command into words, and you cannot use shell forms like redirection. The shell form does not have extra punctuation and implicitly wraps its command in sh -c, but can use all shell features. (These links are to ENTRYPOINT examples but the same syntax works for CMD and also RUN.) Your example has square brackets, like the exec form, but not double-quotes; you should just remove those.

Stylistically, remember that a Docker image has an isolated filesystem. You generally will want to build a working Python application on the host and then package it in a container; so use the requirements.txt file from running pip freeze on the host, rather than trying to rebuild it from scratch in the Dockerfile. Similarly, since the image is isolated, it doesn't usually make sense to have a "home directory", and since the container will also have an isolated filesystem, it doesn't make sense to capture the process's output to a file in the container that will be hard to read later.

I'd rewrite this Dockerfile as:

# Use the standard Docker Hub Python image, rather than installing
# Python on an Ubuntu image.  (You may have a specific requirement
# to use specific base images.)
FROM python:3.9

# Use a short directory name.  Don't make it look like a user's home
# directory.  This will automatically create the directory for you.
WORKDIR /app

# Install Python package dependencies.  The base image will already
# have pip installed.  Do this as a separate step, so that it can
# be cached on rebuild if the requirements.txt file hasn't changed.
COPY requirements.txt .
RUN pip install -r requirements.txt

# Copy the rest of the application in.  You can rename things here if
# you really need to, but it can lead to confusing differences between
# your development environment and the deployed application.
COPY . .

# The main script should be executable on the host system (run
# `chmod +x start.py`) and start with a shebang line
# #!/usr/bin/env python3
# so you should be able to just
CMD ./start.py
# without any redirections or any special punctuation

If you just docker run the built image, it will print its output to stdout; if you docker run -d the image in the background, docker logs will be able to retrieve its logs.