Show HN: #!/usr/bin/env docker run

EDIT: Now I see its badly formatted, Either way, be careful with #! size limits.

My own rule of thumb is that nix-shell is great for quick one-offs and for sharing environments. For local tools and anything else I’m sharing with my future self, it’s usually better to write a nix expression and install it, which gives me access to Nix’s (excellent) rollback system, and lets me upgrade on my schedule, not upstream’s.

* - ‘Latest’ according to whatever Nix channel checkout currently applies. Which you can change, of course, but the point is it’s external to the script.

https://dpc.pw/posts/nix-users-you-can-start-using-rust-scri...

Docker natively supports Windows, and it is low lift to make native Windows images for many common programming environments.

Does anyone use it? No not really. It makes a lot of sense if you need Windows stack stuff that is superior to Linux, like DirectX, but maybe not so much for regular applications.

There is also macOS containers, a project that has a decent proof of concept of a containerd fork that runs macOS container images. In principle there is a shorter path of work for so called host process containers, but fully isolated exists for macOS, it could work with e.g. Kubernetes, and people want it and it makes sense, and it sort of does exist.

The difference between cross-platform and “cross-platform” as you’re talking about it is really having some absolutely gigantic company, like Amazon or Google, literally top 10 in the world, putting this stuff into a social media zeitgeist.

[0] https://unix.stackexchange.com/questions/399690/multiple-arg...

It's like if you have a workshop and you diligently organize all of the different parts into different trays in different units so it's easier to do all the types of work you need to do. You could just have a giant box in the corner where you chuck absolutely everything.. far less complex, but it'd make your day to day work a nightmare.

but you'd then have to work out how to "filter out" the bash commands inside this bash script to make it a valid docker file.

Unless of course, you entirely store the docker file contents inside heredocs. That works fine, but it's not as "cool" as "executing" dockerfiles as a script.

- Easier to grep a collection of single files

- Easier to see what you've got in your collection in a directory listing (whether via a shell or in a web UI such as GitHib)

- Easier to view the contents quickly (`cat`)

- General philosophy that flat is better than nested

The only upside to having an executable Dockerfile is that it's still a valid Dockerfile that you can use with docker build, docker-compose, etc. in addition to being able to execute it.

    cat >Dockerfile <<'EOF'

Here OP created a little hack for building and running a docker container by adding a shebang to a Dockerfile.

Usually it’s a two step process. You first use “docker build” to build the image and then “docker run” to create a container from it. With this little hack you just run “./Dockerfile” and it does both.

It’s cool, but not really useful for most people.

Pretty neat if you're using Dockerfiles, but also highly non-standard so you wouldn't use it in your company repo (unless you want to increase the "what-the-fuck" level of your repo).

It's more of a "look, this is cool" kind of a thing if you're a Linux and container user.

I.e. you can't rely on this working on a POSIX compliant system

The point of this isn't to share this code, it's a demo of the clever shebang line.

    #!/usr/bin/env -S bash -c "docker run --privileged ..."

    FROM docker
    
    RUN <<EOF cat >/other.Dockerfile
      #!/usr/bin/env -S bash -c "docker run ..."
      FROM debian:buster
    EOF
    RUN chmod +x /other.Dockerfile
    
    CMD bash -c "/other.Dockerfile &; ./main"

    $ env "-S echo hello world"
    hello world

At Google Cloud we did this on a team I was on. It was really the only way we could be sure of the environment we were handing off to the customer.