Broken sclirc?

[vargn]

I've been using the same sclirc for months. But all of a sudden when I try to run scli I get this; scli: error: argument subcommand: invalid choice: 'false' (choose from 'link'). So I removed the sclirc from ~/.config and scli runs without problem. I started to edit the sclirc and found that contacts-sort-alpha=false, one-sided=false and group-contacts=false is what causing this. So I removed them and this lets me run scli without getting the error message.

Also, I only have my contacts in the list. There's no separate group category. And my groups don't show up at all. Other than that, scli works like it should. I can send and receive messages. Any ideas on what could be causing this?

scli v0.4.0 signal-cli v0.8.1

UPDATE: The groups in question were created +2 years ago. So in an effort to troubleshoot I created a new group and it showed up in the contact list, I could send and receive messages. But when I closed scli and tried to start it again. I get this;

  File "/usr/bin/scli", line 3245, in <module>
    main()
  File "/usr/bin/scli", line 3223, in main
    state = State(ObservableConfig(args))
  File "/usr/bin/scli", line 2137, in __init__
    self.signal = Signal(cfg.username)
  File "/usr/bin/scli", line 1219, in __init__
    self.reload()
  File "/usr/bin/scli", line 1265, in reload
    g['name'] = self._get_group_v2_cache_name(group_id) or group_id[:10] + '[..]'
  File "/usr/bin/scli", line 1303, in _get_group_v2_cache_name
    name_end = bs.find(name_end_str)
UnboundLocalError: local variable 'bs' referenced before assignment

[f1nbar]

I have been getting the same for the last month or so.

[exquo]

Thank you for reporting this! And for the detailed description of the attempted troubleshooting!

Looks like there are three separate issues here:

• Putting <arg> = false in sclirc causes a crash.
• Old-style groups are not shown.
• New style group's cache file is not found in signal-cli data dir.
• (the "no separate group category" is expected; for that, use group-contacts=true)

The arg = false in sclirc bug was introduced in https://github.com/isamert/scli/blob/9a5a49d81a79cc4a91264d82097215c4940390d7/scli#L3293 so you are probably on the master branch (it has a few commits after v0.4.0). I will look into fixing it shortly. In the meantime, you can just omit those ..=false lines, since False is the default value anyway.

To troubleshoot the groups issue, could you please check your signal-cli's data file's (~/.local/share/signal-cli/data/+YOUR_PHONE_NUM) groupStore: groups contents? Specifically, whether there are any old-style groups there? (Those have shorted groupIds - 25 chars long; also, they have group's name, members and other fields, whereas the new groups only have groupId, masterKey and blocked status). For the new style groups, can you check if there is anything in ~/.local/share/signal-cli/data/+YOUR_PHONE_NUM.d/group-cache dir?

You can also run the scli in the hotfix/114 branch with scli --debug and post the contents of the log (from ~/.local/share/scli/log). It has some debugging printouts about parsing groups. Remember to mask any private info like phone number, group ids in the output.

[vargn]

So, since I created new groups. Me and my group members deleted the old groups. And after a relink with signal-cli I could run scli with new-style groups showing up.

About the one-sided=false issue. I'm now on the hotfix/114 branch and I tried changing it to False. But I'm still getting scli: error: argument subcommand: invalid choice: 'False' (choose from 'link')

EDIT: Maybe I misunderstood, you mean omit those lines completely? Not change it to False?

[exquo]

Ok, we can close the file on the groups issue than. If it reappears, feel free to open a new one. FWIW, I'll at least fix the crash when the group-cache file is not found, and will make the error printed out to logs describe the problem more clearly.

The hotfix branch only contains the diagnostic printouts to the logs to help with troubleshooting the groups part of this ticket. It does not yet solve the sclirc part; sorry I didn't make that clear.

For the workaround I've mentioned - yes, I meant to just delete (or comment out) those lines. I'll fix the crash on ..=false too, but you actually don't need to put them in the config file: currently all the 'flag' options (i.e. those that don't require a parameter after them on command line) have a default False value. So no need to set them explicitly (unless you want to remind yourself when reading the config).

[vargn]

Ok. I'll comment them out for now. Thanks for the help.