MobileRead Forums - View Single Post - FBInk: A small tool/library to print crap on your screen!

NiLuJe · 04-20-2020, 05:29 PM

@taos: I don't see anything obviously wrong at a glance, but it's pretty hard to say what might happen given that pretty much everything is being fed dynamic values

.

On that note:

* I'm all for braces, braces everywhere! This should ensure nothing "bleeds" through a variable. shellcheck should warn about this when it's a real potential issue. I personally pretty much always use braces to keep it simple. And then double-quote it unless it doesn't make sense to.

* Put a set -xe on top of the script, and watch it crash and burn on the first non-zero return code (and/or at least you'll have the actual expanded command being run when something blows up).
(I'd recommend pairing that w/ set -o pipefail, which *should* be supported on Kobo's bb ash, IIRC).

* In the second script, you probably use to ought the -l, --linecount flag instead of trying to parse the full output yourself. It'll be ready to eval straight away, with only the requested information, no need for half-assed attempts at validation.

EDIT: Which you are, I missed it because of the wonky linefeeds ;p. So you can just eval the output, it's always going to be a single eval-friendly line.

EDIT²: Speaking of, if you need the explicit LFs, passing something like "$(echo -e 'Blah\nBlah\nBlah')" works, too

.

* Check FBInk's output, my best bet would be on wonky input tripping getopt, there were some various cleanups on that front somewhat recently.

EDIT: r16051 was v1.16.0-5-gaac4b3e, there have been *numerous* getopt tweaks since (especially around 1.21, IIRC), and the output on getopt parsing errors has been greatly enhanced.

* In the first script, nothing's doing a clear screen except the very first invocation, so, not quite sure what you're describing?

04-20-2020, 05:29 PM	#175
NiLuJe BLAM! Posts: 13,506 Karma: 26047202 Join Date: Jun 2010 Location: Paris, France Device: Kindle 2i, 3g, 4, 5w, PW, PW2, PW5; Kobo H2O, Forma, Elipsa, Sage, C2E	@taos: I don't see anything obviously wrong at a glance, but it's pretty hard to say what might happen given that pretty much everything is being fed dynamic values . On that note: * I'm all for braces, braces everywhere! This should ensure nothing "bleeds" through a variable. shellcheck should warn about this when it's a real potential issue. I personally pretty much always use braces to keep it simple. And then double-quote it unless it doesn't make sense to. * Put a set -xe on top of the script, and watch it crash and burn on the first non-zero return code (and/or at least you'll have the actual expanded command being run when something blows up). (I'd recommend pairing that w/ set -o pipefail, which should be supported on Kobo's bb ash, IIRC). * In the second script, you probably use to ought the -l, --linecount flag instead of trying to parse the full output yourself. It'll be ready to eval straight away, with only the requested information, no need for half-assed attempts at validation. EDIT: Which you are, I missed it because of the wonky linefeeds ;p. So you can just eval the output, it's always going to be a single eval-friendly line. EDIT²: Speaking of, if you need the explicit LFs, passing something like "$(echo -e 'Blah\nBlah\nBlah')" works, too . * Check FBInk's output, my best bet would be on wonky input tripping getopt, there were some various cleanups on that front somewhat recently. EDIT: r16051 was v1.16.0-5-gaac4b3e, there have been numerous getopt tweaks since (especially around 1.21, IIRC), and the output on getopt parsing errors has been greatly enhanced. * In the first script, nothing's doing a clear screen except the very first invocation, so, not quite sure what you're describing? Last edited by NiLuJe; 04-20-2020 at 11:13 PM.