I have written

zip.yaml - it works as I can see.

# zip rule for arara
# author: cis
# version: 0.1
# requires arara 3.0+, zip
identifier: zip
name: Zip
command: <arara> @{unzip}@{program} @{options} @{outputpath}@{name}.@{extension} '@{data0} @{data}' @{encrypt} @{pw}
- identifier: unzip
  flag: <arara> @{ isTrue( parameters.unzip , "un" ) }
- identifier: program
  flag: <arara> @{parameters.program}
  default: zip
- identifier: options
  flag: <arara> @{parameters.options}
#  default: ???
- identifier: outputpath
  flag: <arara> @{parameters.outputpath}
- identifier: name
  flag: <arara> @{parameters.name}
  default: archive
- identifier: extension
  flag: <arara> @{parameters.extension}
  default: zip
- identifier: data0
  flag: <arara> @{parameters.data0}
  default: <arara> @{getBasename(file)}.pdf
- identifier: data
  flag: <arara> @{parameters.data}
- identifier: encrypt
  flag: <arara> @{ isTrue( parameters.encrypt , "--password" ) }
- identifier: pw
  flag: <arara> @{parameters.pw}

A simple test-program:

% arara: pdflatex
% arara: zip
Hello world. 

Lets test the unzip-part!

Especally this works (run in this order):

% #arara: pdflatex
% #arara: zip: { name: archive2 }
% arara: zip: { unzip: true , name: archive2 }


enter image description here

Now to the problem:

If the zip-archive got a password, I could not run zip.yaml to it's end :(

enter image description here

% #arara: pdflatex
% #arara: zip: {  encrypt: yes , pw: aaa }
% arara: zip: { unzip: true }
Hello World again.

What can I do? Thank you!

  • 1
    Wow, you are using arara way more than I do. :) So far your rule looks very nice, I might need to investigate for further improvements. By the way, in the new version (still in development), the YAML format will be dropped in favour of a (way) better, cleaner and easier way of writing rules; it won't be difficult to port the existing rules to the new format and also make use of the new features. :) I decided not to add a compatibility mode with old rules because I'm afraid we might benefit more by moving to cleaner things. Stay tuned, good news will come! :) – Paulo Cereda Jul 24 '14 at 20:27
  • Excuse me, but I am very sceptical about 'not to add a compatibility mode'. There are worldwide lots of rules, users wrote for themself. It could become a burden (stab), when they will realize, that whose rules never run in v4.0. In my opinion, the best way would be, to put v3 and v4 together, not for using the old syntax, but to run (own) good old rules ;) [Let me give you an example - matheplanet.de/matheplanet/nuke/html/viewtopic.php?topic=194815 - o.k., it is german, but I think, the codes will speak for themself. – cis Jul 24 '14 at 21:12
  • 1
    I understand your point of view. :) Sadly, as things are right now, a compatibility layer wouldn't be feasible, it brings a huge complexity which I'm trying to avoid. Rest assured I won't upload the new version to CTAN any time soon to give enough time for users to experiment things and I also for me to collect feedback. I might even write a converter for old rules. I understand your skepticism, but I really have strong reasons to change the format. I'm in the chatroom, just ping me and I can explain a little better. Well, I won't do any crazy things without hearing the userbase. :) – Paulo Cereda Jul 25 '14 at 10:17
  • I might even consider the possibility of forking the project, so our beloved users won't suffer from migration. :) And of course, update the current tool. :) – Paulo Cereda Jul 25 '14 at 20:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.