Opened 10 years ago

Closed 10 years ago

Last modified 10 years ago

#4725 closed Bug (fixed)

transmission-remote does not reflect status in returncode

Reported by: Xake Owned by: jordan
Priority: Normal Milestone: 2.50
Component: Daemon Version: 2.42
Severity: Normal Keywords:
Cc:

Description

Today I was planning on a little script for my torrent handling when i found somethiing that created problems for me: even if transmission-remote fails it still returns ok.

Way to reproduuce: transmission-remote -a "foo" && echo "bar"

transmission Will give you an errormessage about thé obvious non existing torrent. then echo is still executed.

Attachments (1)

transmission-remote-returnstatus.patch (484 bytes) - added by Xake 10 years ago.
And here is the fix.

Download all attachments as: .zip

Change History (10)

comment:1 Changed 10 years ago by Xake

On a note: if it cannot connect to the daemon the return code is 1, so the return code currently seems to only reflect if remote was able to connect ot the server or not...

Changed 10 years ago by Xake

And here is the fix.

comment:2 follow-up: Changed 10 years ago by x190

Is #4409 related to this?

comment:3 Changed 10 years ago by Xake

i actually Do not know. It seems to me like flush() for http status 409 recurses, but never takes thé status of thé recurse into account, so even when that fails the statuscode is never changes.

comment:4 in reply to: ↑ 2 Changed 10 years ago by Xake

Replying to x190:

Is #4409 related to this?

After taking another look: they are unrelated. It probably touches thé same code, but he does a complex add that thé argument verification of transmission has problems with probably even before trying to connect to thé server. however i Do a add as simple as it can get and transmission sets a returncode which signals that it succeded as Long as it was able to connect to thé daemon, just because thé status of thé acctual command is ignored.

one Line fix. patch Works for Me, and has yet to break anything.

comment:5 follow-up: Changed 10 years ago by rb07

Its a regression (i.e. it used to work) very similar to an old one: #3241 that was fixed.

comment:6 in reply to: ↑ 5 ; follow-up: Changed 10 years ago by Xake

Replying to rb07:

Its a regression (i.e. it used to work) very similar to an old one: #3241 that was fixed.

Ugh. Transmission really needs some kind of test suite and regression-testing... I think I have to set one up myself only to be sure that the version of transmission I just upgrade to does not break my scripts.

comment:7 in reply to: ↑ 6 Changed 10 years ago by jordan

  • Component changed from Transmission to Daemon
  • Milestone changed from None Set to 2.50
  • Owner set to jordan
  • Status changed from new to assigned
  • Version changed from 2.41+ to 2.42

Replying to Xake:

Replying to rb07:

Its a regression (i.e. it used to work) very similar to an old one: #3241 that was fixed.

Ugh. Transmission really needs some kind of test suite and regression-testing... I think I have to set one up myself only to be sure that the version of transmission I just upgrade to does not break my scripts.

After you've written it, be sure & submit it to trac ;)

comment:8 Changed 10 years ago by jordan

  • Resolution set to fixed
  • Status changed from assigned to closed

r13182 daemon/remote.c: (trunk daemon) #4725 "transmission-remote does not reflect status in returncode" -- fixed with patch from Xake

comment:9 Changed 10 years ago by jozechu

Transmission-remote shipped with 2.50 still showing wrong status codes.

When all of them are paused, it shows a empty string for all of them. If you wake some but the first, it returns empty string for all torrents ID lower than it, and the one you started and later(ID sorted) shows the same status despite their real status.

This issue will break any script based on the status. I was looking for a list of status returned by transmission-remote and nothing...could someone give me some insight? Thanks.

Last edited 10 years ago by jozechu (previous) (diff)
Note: See TracTickets for help on using tickets.