Clara HD Running script from NickelMenu returns too early

[nickelclone]

I have NickelMenu 0.5.4 on a Kobo Clara HD with firmware 4.38.23038.

I have the following in my NickelMenu config:

menu_item :main :Dropbox Pull :nickel_wifi :enable
  chain_success :nickel_wifi :autoconnect_silent
  chain_success :cmd_spawn :quiet :/mnt/onboard/.adds/rclone/sync.sh
  chain_success :nickel_misc :rescan_books_full
  chain_failure :dbg_toast :Failure!

In sync.sh I have:

#!/bin/sh

# Constants
readonly rclone_dir="/mnt/onboard/.adds/rclone"
readonly rclone_remote="Dropbox:"
readonly book_library="/mnt/onboard/Books"

# Start sync
qndb -m mwcToast 1000 'Starting Dropbox download...'

if ! "$rclone_dir/rclone" \
  --ca-cert "$rclone_dir/cacert.pem" \
  --log-file "$rclone_dir/rclone.log" \
  --ignore-checksum --size-only \
  --verbose \
  copy "$rclone_remote" "$book_library"
then
  qndb -m mwcToast 8000 "Error in download!"
  exit 1
fi

qndb -m pfmRescanBooksFull

You'll notice I'm using qndb (from NickelDBus) to show a message and rescan books. I would like to uninstall NickelDBus and use just NickelMenu, but the issue is that the config above does not work as desired: cmd_spawn triggers and runs fine but for NickelMenu chaining purposes it returns immediately and rescans the library too soon.

I also tried cmd_output but that just seemed to wait the full timeout and then error, before even trying to run the script (this is apparent from reading the log while it's happening)

Finally, I also tried not using a script and running rclone directly in the cmd_spawn, but that also exited too soon.

Again, sync.sh does run and complete as expected, it is only in the context of NickelMenu that it's going to the next action before it should.

[qkqw]

As you spawn a command, it will immediately return and execute the rescan. So you'd need to do everything inside the script and use qndb.

Also, see here for a working rclone setup: https://www.mobileread.com/forums/sh...9&postcount=11

[nickelclone]

Originally Posted by qkqw

As you spawn a command, it will immediately return and execute the rescan.

That’s what I thought. But as I mentioned, cmd_output isn't working either. I did see another post on these forums suggesting cmd_spawn should work with chaining but I lost the link.

Originally Posted by qkqw

Also, see here for a working rclone setup: https://www.mobileread.com/forums/sh...9&postcount=11

Oh, I have a working rclone setup, and that post was a major help in getting to that state. Thank you! If you squint, you'll notice my script is inspired by yours. I also have a suggestion for the bit on waiting for a connection, which I also modified to be (for me) shorter and simpler:

retries=60

while [ "$retries" -gt 0 ]
do
  ping -c 1 -w 3 '1.1.1.1' && break

  sleep 1
  retries="$((retries - 1))"
done

Thank you again.

[qkqw]

In that case I'd telnet to your Kobo and run the script manually. It might be you use a keyword the reduced shell does not support.

[nickelclone]

Originally Posted by qkqw

In that case I'd telnet to your Kobo and run the script manually.

That’d be extra work when the goal is less. I'd rather haver a leaner install and not need NickelDBus but it's not worth it to have a worse experience because of it.

Originally Posted by qkqw

It might be you use a keyword the reduced shell does not support.

That doesn’t make sense from a Unix shell perspective. The commands are run with /bin/sh -c, if there were a keyword it didn't support then it wouldn’t work at all. But that’s not the problem.

I just checked NickelMenu's code directly. Indeed, with the current implementations of cmd_spawn and cmd_output it doesn't seem feasible to do what I want.

Oh well. Thank you for the help.

[qkqw]

Well, something in your script doesn't seem to work. You can just login via telnet once and run the script to see if there's any output. No additional work necessary. Also, Kobo uses a reduced shell so it might very well be that some commands do not exist or behave differently.

[nickelclone]

No, the problem is not the script. The script works fine, it already did before I made the first post and I said as much from the start. And it’s not related to the shell either, because again, that’s not how that works. The “issue” (in quotes because it’s not a bug, it’s working as designed) is in the caller, I confirmed this in NickelMenu’s code. That’s fine, I’ll just leave with the tradeoff or submit a PR. There’s no point in speculating further, it’s crystal clear now where the limitation lies. It’s not the script.