Increasing transmission-remote -l parsability

[q3cpma]

Hello.

Parsing the output of transmission-remote -l is a pain because:

• The current way of parsing "correctly" is based on column counting, and doesn't work when the ratio overflows (which is often).
• Using space as a delimiter doesn't work because some fields like "Have" may or may not contain a space.

Would a patch adding a --list-machine to use a tabulation between each field be accepted?

[xavery]

I don't mean to sound disrespectful, but what's the use case where parsing a program's output is preferable to just using the JSON output via the RPC interface? To use transmission-remote, your session's RPC interface must be available and you must have the correct credentials anyway - might just as well use it directly.

[valcomm]

Let me try to answer why not RPC interface. To use RPC there are requirements that make requests by command line utility very hard. For example: authorization headers, tag value, token (which forces to actually do two requests).
That makes RPC interface available only for someone who knows programming languages with a working library.

I needed more info than transmission-remote provides and I had to write my own RPC library for the language I know.
But still I use transmission-remote and I would like to ask some modification for it.
How about an additional switch that would print returned JSON to STDOUT? Then people that need their own processing/displaying could use some JSON filtering/processing command line tools (e. g. jq).
Using \t instead of " " is just a small step to the flexibility/power that would be available with my suggestion. And it's not a huge change.

[q3cpma]

On Sat, Dec 11, 2021 at 05:05:27PM -0800, Daniel Kamil Kozar wrote: I don't mean to sound disrespectful, but what's the use case where parsing a program's output is preferable to just using the JSON output via the RPC interface? To use `transmission-remote`, your session's RPC interface must be available you must have the correct credentials anyway - might just as well use it directly.

Your question is equivalent to wondering why such plaintext output exists in the first place. The whole point of this feature AND my request is to easily parse such output with the standard POSIX tools (awk, cut, etc...). And for this, you need a delimiter. So, either an option to get such an output or fixing the ratio overflow thing as a band-aid to allow inserting the delimiters ourselves is necessary for this tabular output to be useful for more than human viewing.

[ckerr]

Would a patch adding a --list-machine to use a tabulation between each field be accepted?

A patch to add this feature would be fine. "Would a patch be accepted" depends on more than one factor though, e.g. if the patch is 2000 LOC and leaks like crazy I'll send it back for revision 😸