Bin/4G/... (flash.sh) from the archive; missing #! for interpreter; may also continue after errors

[paigeadelethompson]

I came across an issue on the forums: (from here: https://forum.clockworkpi.com/t/please-help-i-may-have-bricked-my-lte-modem/14987/6 )

They seemed pretty uncertain about whether or not the script did what it was supposed to (they mentioned first that they were certain it was correct, their words:

All was going well and everything was happening exactly like expected in the instructions. I was at the point of running ./flash.sh and even that output looked pretty much exactly like on the screen, right down to finishing up with...

finished. total time: 3.558s
rebooting...

And they went on to explain after rebooting the device that the modem was no longer detected and it just sorta reminded me of the way fastboot works.. becuase it is fastboot however I've never had one go bad on me that I can think of at all actually but it seems apparent that whatever went wrong, happened as a result of them running flash.sh so I decided to look there and see how this script works, and I noticed two things off the bat:

• Missing interpreter shebang (eg: #!/usr/bin/env bash without this it could literally default to virtually any shell which I don't see as behing much of a problem here given that there's no control statements or variable expansion being done but in terms of what is supported that should probably be definitive otherwise this defaults to /bin/sh. YMMV is what I'm getting at and you probably shouldn't rely on /usr/bin/env either but I feel llke that's better than nothing.
• script should (probably) be set -e because there are a list of commands any one of which could fail and by default the script will continue trying to run the remaining commands in the script; this probably shouldn't be the case if you're trying to determine what specifically is failing for users when they're running it. It seems like in any case, the failure mode should be to stop running commands early if one command fails rather than continue all the way to sudo fastboot/bin/fastboot reboot which if it's even remotely recoverable before that will almost certainly assure that it won't be based on what people are apparently experiencing with it..

[paigeadelethompson]

It might be a good idea to explore some pre-validation steps like for starters the script should probably just be run with sudo itself rather than running sudo multiple times, there's a couple of things worth considering about fastboot actually:

https://manpages.ubuntu.com/manpages/xenial/man1/fastboot.1.html

those that stand out to me are the -p and -i options are not totally unworthy but I won't judge somebody for skipping those

apparently there is a fastboot getvar all info to query devices but this maybe limited to certain devices.

[paigeadelethompson]

Also I just wanted to point one thing out:

I wouldn’t call that recommendation as an “upgrade”. You should only replace the preloaded firmware if you are absolutely sure you are not able to connect to the network with the firmware. Replacing runs the risk of losing certain features.

I'm not disagreeing with that statement at all but it does very little good to tell somebody who just bricked their modem "you misunderstood the meaning of upgrade; perhaps these tools should be made available upon request rather than a suggestion in the Wiki because they could certainly stand to be improved in terms of what could be hypothetically supported. Chances are if somebody is trying to upgrade their modem firmware there's a reason worth considering from the vendors point of view and I don't think many people would care too much if you gate-kept it given that the consequences for it not working correctly are so perilous.