Skip to content

Conversation

@madejackson
Copy link
Contributor

This small change in the code allows for usage of the exec form in CMD and ENTRYPOINT commands.

The exec form is functionally superior to the shell form allowing for more complex executions including f.e. the && and || operators and more.
Meanwhile it can still behave as the shell form does, when appending [ "/bin/sh", "-c" ] to the beginning of the exec form array.
Docker Documentation

Specific table comparing the different usages of exec and shell form in docker:
grafik

I have tested it against several images of my own market and on existing machines and it seems to work flawlessly. Existing templates using shell form (string) are converted to an array containing a single string element.

@cla-bot cla-bot bot added the cla-signed label Jan 7, 2026
@madejackson
Copy link
Contributor Author

This probably also fixes this one: #387

@azukaar
Copy link
Owner

azukaar commented Jan 20, 2026

I dont think "Existing templates using shell form (string) are converted to an array containing a single string element." is the correct behaviour tho, because Docker is going to see it has
["ls something"]
instead of ["ls", "something"]

which means bash is going to receive a single command with a space in it - needs some testing before it can be merged

@madejackson
Copy link
Contributor Author

Yeah I agree.

There are probably some setups running atm which would break with this code. You can even see this in my commit, I had to change the mongo cmd parameters, otherwise it was failing to start.

Though tbf those templates usually were inconsistent with other, plain docker setups and ressources/documentations anyway and this commit just reverts that discrepancy.

To be 100% consistent with docker, cosmos should execute single strings as one line, while appending /bin/sh -c as a prefix. From a functionality standpoint, this is not strictly necessary though as it can be appended manually.

@madejackson
Copy link
Contributor Author

madejackson commented Jan 22, 2026

I'm gonna test some apps from the official market with this PR with the following procedure:

  1. Install app via Market
  2. Check if it runs successfully
  3. Force recreation via Cosmos Compose
  4. Check if it still runs successfully

So far tested Apps:

  • ✅ Actual grafik

  • ✅ Audacity grafik

  • ✅Audiobookshelf grafik

  • ✅Baserow grafik

  • ✅Bazarr grafik

  • ✅Blender grafik

  • ✅Cachet grafik

  • ✅ Calibre grafik

  • ✅Calibre-Web grafik

I think i stop here with alphabetical test and commence only the ones with entrypoints / commands in their template:

  • ⚠️ Discourse --> unrelatedly broken: uses bitnami image

  • ❌Nextcloud

  • ✅Ntfy grafik

  • ❌Photoprism

  • ⚠️SearXNG --> unrelatedly broken: Template seems to be broken in the market

  • ❌Trip

@madejackson
Copy link
Contributor Author

OK so from my testing you are correct, @azukaar

The apps with commands containing spaces break (Nextcloud, Photoprism, Trip). The rest works as expected.

Take the app Trip for example:
The official compose file uses command: ["fastapi", "run", "/app/trip/main.py", "--host", "0.0.0.0"]
while cosmos uses: "command": "fastapi run /app/trip/main.py --host 0.0.0.0",
(and then somehow internally rewrites this to the correct one above. So it's neither of the behaviours of compose, it's rather something in between, hence never 100% compatible / feature complete)

This PR fixes that and mandates cosmos to use the same setup as the official documentation from Trip:
"command": [ "fastapi", "run", "/app/trip/main.py", "--host", "0.0.0.0" ],
WHILE still allowing to have the behaviour of shell form commands via appending "/bin/sh", "-c", as a prefix.

So as soon as this PR gets merged, we need to also merge azukaar/cosmos-servapps-official#200 into the servapps (which I just created). This way, new setups will work regardless.
Existing setups for those apps will break though, so this would be a breaking change. Maybe implement some migration logic to mitigate that OR at least inform users about it.

@azukaar
Copy link
Owner

azukaar commented Jan 22, 2026

Hmm yes that's what I thought. So it's good to migrate the market but it's not that simple, if we do that we will break all the backups of cosmos-compose that currently have this as a string. It will also break docker-compose files that have the string version which, while inferior, is more common.

The missing pieces are

  • there needs to be a migration path from older format to newer format of cosmos-compose
  • docker compose that have strings need to be converted before being sent for import

Both of those things happen in docker-compose.jsx but it is a very (overly) complicated part of the code so I would understand if that's not something you want to give a go at

@madejackson
Copy link
Contributor Author

I see, let me have a look at that file (docker-compose.jsx) when I got some spare time.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants