./lib/deviceinfo.lib: line 17: {: syntax error: operand expected (error token is "{") #38
Closed
opened 4 years ago by PLNech
·
10 comments
Loading…
Reference in new issue
There is no content yet.
Delete Branch '%!s(<nil>)'
Deleting a branch is permanent. It CANNOT be undone. Continue?
When running
./adebar-cli
on myoneplus
config (which is barely modified from sample), I get the following error in the middle of the output:Any idea what could be the issue here?
(Version: git cloned commit
175a9ee793
)(System:
Debian GNU/Linux 9.5 (stretch)
)The file this error is reported for hasn't been touched in over a year. Taking a look at the line, I see nothing wrong syntax-wise (and your Bash version should be OK on stretch) – which leaves "device specific" things here. Do you have another device to cross-check whether this error happens? Further, with the oneplus connected, please run
(optionally redirect it to a file) and check whether it contains
mServiceState
(if not, that would explain the error – though that would be very strange). If you could attach (or pastebin-link) the output, that might be helpful as well.Another thing you could try for testing is adding a line before the error occurs (i.e. before line 17 in
deviceinfo.lib
):That should tell us clearly whether the variable is set.
I have this problem as well, I've cloned into the current repo state.
https://pastebin.com/JGmRrHKN
Thanks for the dump, @Catfriend1 – that got me started! I'm not at my machine so I cannot run the command myself ATM – but looking at a complete dump I made a couple of days ago it seems your devices format the output differently:
Now from one of my devices:
Now let's take a look at the error message you reported, and be surprised:
(error token is "{")
– your devices name all variables (the order seems the same;1 1
in my dump is a device in airplane mode, so no calls and no data – and of course no provider, network etc (null null …
)). As a work-around until I can find a fix, please ignore the error or comment out line 17 if it bothers you; you won't have those details in either case, but all else works.Could you two please specify which device you are using and which ROM and Android version it is running?
OK folks, could one of you try to replace line 17 by the following, and let me know the outcome (including whether the "Service state" for each SIM has multiple "su-bullet-points")?
I cannot test this myself as none of my devices reports
mServiceState
that way.@IzzySoft After replacing line 17 I got the following
https://pastebin.com/vSgrGMNG
I'm having a new error now:
I'm on Xiaomi Mi8 running MIUI 10 (Android 8.1.0 based)
@Catfriend1 OK, that means my fix for "line 17" works. Just the leading bullet point is missing (adding that). The "RIL:" line might need a cosmetic fix, though (too many line breaks in the Markdown, but that doesn't show when rendered).
Just wanted to add the changes when I saw your PR; what are the other two changes about, removing line breaks? Never noticed any that hurt there.
Hm, looks like you removed the CR and replaced it by a NL. Sure that is what it should be? As it's no PR yet, please let me push the changes I already had commited locally, and let's take care for those line breaks separately (if needed).
Also, could we move the partitions error into a separate issue? Again, it would be helpful to have the Markdown output from that session. Especially I'd need to know what source is mentioned – and then, if possible, the output of the corresponding "collector command". From the error message I can say there is a line that has no size; I'd assume some header, but I cannot tell.
Declaring this issue solved then. Let me know if I'm wrong, so I reopen.
@IzzySoft
I didn't change the CR line break intentionally, I think it came from GitHub Desktop. So your commit is fine only changing what needs to be changed here. :)
Thanks for fixing it 👍
Thanks for your support in fixing it (no tester, no commit 😉) Glad we got it tackled. Now for the next two (partitions and unlock codes). You open a new issue for the partition error with the input requested, and I'll dig in. Looks like I must reject your PR on the keycodes (see background there) – but I already have a solution in mind.
No problem, thank you too. I'll do so tomorrow...