pushd is not posix sh
llandsmeer opened this issue · comments
Hi, another small issue :)
Executing make kobo gave me:
pushd Kobo && zip -r ../Release/FBInk-v1.21.0-31-gfdd7300.zip . && popd
/bin/sh: 1: pushd: not found
Quick fix with:
diff --git a/Makefile b/Makefile
index f4694fe..6036e03 100644
--- a/Makefile
+++ b/Makefile
@@ -621,7 +621,7 @@ kobo: armcheck
cp -av $(CURDIR)/README.md Kobo/README.md
cp -av $(CURDIR)/LICENSE Kobo/LICENSE
cp -av $(CURDIR)/CREDITS Kobo/CREDITS
- pushd Kobo && zip -r ../Release/FBInk-$(FBINK_VERSION).zip . && popd
+ (cd Kobo && zip -r ../Release/FBInk-$(FBINK_VERSION).zip . )
mv -v Release/FBInk-$(FBINK_VERSION).zip Kobo/
libunibreakclean:Not sure if that is something you want fixed. Shall I just sent a pull request next time (which you can ignore if you don't want the fix)?
Furthermore, I came across some small issues when trying to use fbink.h from C++, which can be fixed with a extern "C" and #define restrict __restrict__. But maybe C++ support is not a design goal.
Also, since you seem to be the author of KFMon and I have some questions about its use, whats the best way to contact you - if you're willing to answer some questions? :)
Kind regards,
Lennart
Today is apparently not my day as far as posix sh is concerned... ^^ (context).
In any case, that's definitely something worth fixing, since I don't think anything else is really GNU-ish in there ;).
IIRC, the subshell might be unnecessary though, as each line in a Make recipe is already a subshell ;).
Otherwise I'd prefer a cd - on the tail end, just for clarity (unless that's also a GNU extension ;p).
Definitely also fine with a PR for C++ compat, if it's behind a __cplusplus guard, it's essentially harmless ;).
As for KFMon, I'm perfectly fine with discussions taking place in an issue. Or you can ping me on KOReader's gitter, or via PM on MobileRead ;).
Sidebar: you probably don't actually want to use the "kobo" target, since it does a bunch of packaging steps no-one but me probably cares about ;).
Sorry for the late reply, some things came up. Posix compliance isn't that important for me, but my make apparently uses posix sh? And yes after fixing that I quickly found out that the kobo target wasn't the right one 😄
Okay since its a small question, ill just ask it here then. What does a application have to do, after being started by KFMon, to stop Nickel from responding to inputs in the background? Grabbing evdev devices seems to work somewhat, but I think I should just killall nickel? Or is there a nicer way?
AFAIK, there's unfortunately not much that can be done short of killing nickel and its friends.
Which gets slightly problematic if you want to restart it without a reboot, because it's very finicky about how the environment looks.
In practice, that implies inheriting a few of its env before killing it: https://github.com/koreader/koreader/blob/95d18fe8d9cc5f21763eaa76bd7960d0a746a309/platform/kobo/koreader.sh#L94-L102
And then being somewhat careful about how you go about restarting it: https://github.com/koreader/koreader/blob/master/platform/kobo/nickel.sh
IIRC, if you simply SIGSTOP/SIGCONT it, the input events will still accumulate and flood nickel on CONT.
Been a while since I double-checked that, though, and I may be confusing what exactly happens here with what happens when you do that to the Kindle WM ^^.
So, if it's a short-lived app, it might be worth a try.
On a somewhat related note, If you're concerned with input events, nickel grabs event0 exclusively by default (that's physical buttons and synthetic gyro events). Touch input isn't grabbed, on the other hand ;).
(If need be, there's a kobopatch patch to prevent the EVIOCBGRAB on event0).
Woah thats a bit more involved than hoped :) Thanks so much for the thorough explanation! 😄
I think I'll go with stealing the shell scripts then. They look like they're full of hard learned lessons :) Or maybe SIGSTOP/SIGCONT + ptrace into Nickel to flush the input streams, if I ever figure out how to do that last step
Note that you need to be careful when ptracing nickel, as if you do it at the wrong time (I haven't yet figured out exactly when), you'll cause nickel to segfault. Doing a PTRACE_SEIZE seems to prevent this most of the time, though.