> conditional processing in sqlite3 shell Why not invert it? SQLite is designed primarily to be driven by a program *other* than its command shell. The simplest method is to put your logic in a separate shell script that makes `fossil shell` calls under control of the logic in the script. Worst case, you can fall down to `fossil sql` calls. If that's not powerful enough, Fossil's 2-clause BSD license and straightforward C code will let you extract its custom functions and whatever support infrastructure (such as SQLite) needed to run those functions against the Fossil repo DB. > `/bin/dash` Dash provides little more than what POSIX specifies, so it doesn't understand `[[` constructs. You're lucky it has built-in `test(1)`/`[` at all. :) This gets us to Larry's point about `system(3)`: it's [documented][1] to use `/bin/sh`, which is Dash on your system. There is no documented way to make it use another shell, almost certainly for security reasons. Even if you move this to another system where `/bin/sh` is Bash or Zsh, I'll probably drop all of its non-POSIX features because of the `argv[0]` value. Only when called by the shell's full name do you get the post-POSIX extensions. > `.shell /bin/bash -c` Bleah. Quit trying to arm-twist it into working inside out and upside down. You're just going to make yourself dizzy. [1]: https://linux.die.net/man/3/system