(arara) make rule failure non-fatal

Question

I have a rule that attempts to download the bibliography as part of the build, but I would preferably have the option to have it soft-fail when the download fails, as I probably have a up-to-date copy from the last download. I tried the script below (localhost replaced with ocalhost to avoid the SE filter), with the following two problems:

1. I get the error "I'm sorry, but the default value set for the argument 'conditionalFail' of the 'zoterobib' task (referencing the 'zoterobib.yaml' file located at 'C:\Program iles\arara\rules') has an unavailable variable/method in the rule context: 'base'"
2. If I remove the @{base} reference, the rule fails reliably and silently (iow, the || ... do not seem to get executed)
3. if I add the || ... directly to the commands line, it does what I expect it to do, but then it will always soft-fail, and I would prefer this to be an explicit option

.

!config
# Pull bibliography from zotero as part of build
# author: Emiliano Heyns
# last edited by: eeh, Dec 2nd 2013
# requires arara 3.0+
#
# Sample usage
#
# % arara: zoterobib
# % arara: zoterobib: {format: biblatex}
# 
# for windows, use http://www.confusedbycode.com/curl/#downloads
identifier: zoterobib
name: ZoteroBib
commands: 
- <arara> @{ isWindows( "cmd /c ", "" ) } curl --connect-timeout 1 -s -o "@{base}.bib" "http://ocalhost:@{port}/better-bibtex/collection?@{collection}.@{format}" @conditionalFail
arguments: 
- identifier: base
  flag: <arara> @{parameters.base}
  default: <arara> @{getBasename(file)}
- identifier: port
  flag: <arara> @{parameters.port}
  default: 23119
- identifier: format
  flag: <arara> @{parameters.format}
  default: biblatex
- identifier: collection
  flag: <arara> @{parameters.collection}
- identifier: continue
  flag: <arara> @{parameters.continue}
- identifier: conditionalFail
  default: <arara> isTrue(@continue, "|| (echo could not download @{base}.bib && exit 0)")

Answer 1

The reason @{base} fails is because, for arguments, the scope is limited only to the parameters map. That means one argument is unavailable to the other. I'm still thinking of how should I evaluate arguments and in which order. As a workaround, I suggest you to keep the two arguments that are related (since arara only allows directive parameters that are expected in the rule context), but process only one using the two values from the map (well, if I understood what you are trying to achieve. :) I might be wrong as well).

Now, about the second part of your question: for security reasons, arara does not allow subshells calls, and everything that gets executed by it is trapped inside a shell sandbox (well technically it's not a sandbox, but in the sense that the environment is restricted). So a chain of commands (via redirection/pipes, logical paths) won't have the desired behaviour. Sorry. :(