[zamadatix]

Never thought I'd see hackers saying INI format looked ugly of all things. It's basic, sure, but that's a good thing for something meant to be easily editable by hand from any editor. Otherwise, it's just key value pairs in named sections, how ugly can it be about that?

[jjgreen]

key-value pairs where the = cannot be surrounded by spaces, so I have to write

  [Service]
  Type=oneshot
  WorkingDirectory={{ home }}/current/
  Environment=RAILS_ENV=production
  ExecStart=/bin/sh -lc "bin/db-backup --verbose"

which fills me with sadness

[voxic11]

Whitespace immediately before or after the equals sign is completely ignored by the parser. Its the standard INI format.

[Eduard]

Standard INI format™:

https://specifications.freedesktop.org/desktop-entry/latest/...

[yjftsjthsd-h]

What? You absolutely can have spaces; most of mine look more like

  [Service]
  Type             = oneshot
  WorkingDirectory = %h/current/
  Environment      = RAILS_ENV=production
  ExecStart        = /bin/sh -lc "bin/db-backup --verbose"

[jjgreen]

Friend, you have changed my life

[weavie]

Is this one of those cases where at one point you had an error in the file and you figured it was down to spaces? You fixed that issue, it still didn't work but from that point you never thought to question the assumption.

I find myself doing this sort of thing all the time..

[jjgreen]

Somewhere in my head I had that spaces caused a syntax error, and the UI for systemd is not obvious when you first start using it ... so if it's working then leave well alone. I'll be making all of my .service files (not so many) human-readable in the near future!

[troyvit]

That was (cough still is) ddclient for me.

[bblb]

My epiphany a month ago was that I can use

   Environment = MULTIPLE=environment VARIABLES="in single line"

[bingo-bongo]

Just remember: never use Environment= for secrets, since they are visible to all users on the system.

(Use EnvironmentFile= instead)

[ramon156]

TOML would look a lot more quiet, but I'm not sure if TOML would be a good fit

[kevinmgranger]

unit files barely have any nesting, so the INI-like format is already 90% of the way towards TOML, no?

[OJFord]

I suppose some things that can be multiply specified would be arrays, and maybe there'd be a stronger argument for combining say timer & service in the same file (or that it could be optional) given some structure.

Personally though I'm not really a fan of TOML when the data is highly structured - prefer YAML even a lot of the time for some visual indication. (If I were writing a parser, I have zero doubt I'd rather parse TOML!)