Did you consider to print args vertically?

[anordal]

Just a tip:

An inconvenience with the original pkg-config is that command substitutions like cc $(pkg-config --cflags) … don't work when pasted into fish:
fish-shell/fish-shell#982

This is because fish only splits command output by lines. Which means that printing items linewise is the way to be fish friendly. Maybe there are counterarguments I haven't thought of, but this is something that comes to my mind if I had the opportunity to redo it.

[skeeto]

Quick summary: You can already achieve what you want using "eval" as noted in the original thread. Even more, that's actually the most correct answer for any POSIX shell, too, so fish is not a special case. $ eval cc app.c $(pkg-config sdl2 --cflags --libs) It's probably worth writing a whole article on this, but I'll at least get my thoughts down here and now. Unless I missed it, the linked fish issue dances around it but never quite hits on the fundamental point: Despite the documentation and most common use case, pkg-config output is not designed for command substitution. It's designed for evaluation. That is, pkg-config output is a raw shell script fragment designed to be concatenated with other fragments, then evaluated exactly once. It's coincidence that it also works for POSIX shell command substitution in most cases, but that's not so for most fish cases. This is a subtle, easy-to-miss detail, and it took me writing an entire pkg-config clone to notice. I'm not sure if the pkg-config designers ever understood it given the misleading documentation. I suspect the pkgconf authors *did* notice because none of their documentation mentions shell command substitution. Unlike eval, POSIX command substitution semantics do not allow pkg-config to pass arguments containing spaces. If there was a command substitution mode — either via flag or auto-detected — when faced with such a case it would need to give up and exit with a non-zero status, which to make matters worse, would likely be silently ignored. For example, I'll use printf to display the arguments it sees, one per line, and I want to communicate two arguments "a b" and "c". I'll emit it from echo in the same format as pkg-config: $ printf '%s\n' $(echo 'a\ b c') a\ b c There's no way for the subcommand to prevent the outer command from splitting the first argument. fish sees a single argument "a\ b c". Add an eval and it's fixed in POSIX and fish: $ eval printf '%s\\n' $(echo 'a\ b c') a b c (Note the extra printf backslash since the format argument is evaluated twice.) That's what I mean about it being "most correct" even for POSIX shells. Caveat: The above applies only to --cflags/--libs, and not to other queries like --modversion, which are not intended to output shell script fragments. The bad news doesn't end there: Most .pc files are written incorrectly and so do not work in cases where eval *would* work but command substitution would not. Don't blame the .pc file authors though. The pkg-config documentation is wrong on this point, and even the pkgconf authors get this wrong in their own .pc files. The pkg-config semantics also don't help, and all these .pc files could be correct as-is given better semantics. Here's an example.pc using "prefix" in the conventional way: prefix = /usr Cflags: -I${prefix}/include If this .pc file is installed under a path containing a space, like "/Program Files/lib/pkgconfig" it won't work, even in fish: $ eval printf '%s\\n' $(pkgconf/b/pkgconf --cflags example.pc) /Program Files/include The correct way to write this is with quotes around either the whole argument or just around the variable: prefix = /usr Cflags: "-I${prefix}/include" With the quotes it works the intended way everywhere: $ eval printf '%s\\n' $(pkgconf/b/pkgconf --cflags example.pc) /Program Files/include The best way to fix this isn't to try to get everyone to use quotes. It's to change the semantics, especially since the original semantics gives the wrong results in probably every practical case. I'm considering doing so with u-config by default. So here are possible actions I'm considering: * There's no point in a "--command-substitution" flag to change the output because it's inconvenient, incompatible, and too complicated, so nobody would use it. * If u-config can reliably and reasonably detect that it's being used in a command substitution, it changes behavior: (1) arguments are delimited by newlines, which is compatible with all command substitution flavors, (2) it does no meta-character escaping, (3) it returns with a non-zero status when an argument contains a space, and (4) it buffers the entire output so that nothing is output unless the command is successful. * Change u-config to always place newlines between parameters, which is now trivial, and I've already been trying it out. This seems to work fine with POSIX eval. It's also easier to understand the output and fish can mostly get away with dumb shell command substitution. The only case I can contrive where it won't work is if you're literally constructing a shell script by concatenating outputs. At best that's very unusual, and it shouldn't dictate the default. * Treat "prefix" as special and wrap its overridden value in quotes when it contains a space. This solves most quoting issues surrounding "prefix" which is of particular importance on my main target (Windows). However, this breaks .pc files (in special cases) where the authors did the right thing. On the other hand, I have not seen any such case in the wild. Every use of quotes I *have* seen is incorrect. I considered other changes like field splitting before variable expansion, but it would break real world .pc files I've seen. I think I'm going to make the last two changes right away, the first of which would make shell substitution work in fish when it also already works in POSIX shells. Detecting shell substitution (second item) would mean it always works reliably for fish shell substitution (except paths containing newlines, which is too insane to consider), and a little more reliably for POSIX shell substitution.

[skeeto]

I believed has long been resolved, so I'm closing.