The position of the -d option in the arguments matters

[cszach]

Description

If the -d (or -D) option is specified after, say, --theme, the check done in --theme becomes meaningless as REVEAL_PATH then changes.

This happens because reveal-init reads arguments from left to right and perform a certain action upon encountering an argument (as a result of reading it). When -f (or any of its longer equivalent options) is encountered, reveal-init checks if the specified input theme for that option exists, which involves REVEAL_PATH. REVEAL_PATH is also changed immediately if reveal-init encounters the -d (or -D) option, assuming the new REVEAL_PATH is valid. Thus if the -d option is thrown after the -f option, the theme existence check done when -f is encountered uses the incorrect REVEAL_PATH.

Steps to reproduce

# Create a clone of the existing valid REVEAL_PATH
cp -r $REVEAL_PATH test_reveal
# Delete the moon theme in the new copy
rm test_reveal/css/theme/moon.css
# This is executed without any trouble
reveal-init -f moon my_slides
rm -rf my_slides
# This is executed with reveal-init knowing that moon.css is absent, which is as expected
reveal-init -d test_reveal/ -f moon my_slides
rm -rf my_slides
# reveal-init knows that moon.css is presented in the original REVEAL_PATH,
# but has no clue that the later-assigned REVEAL_PATH doesn't have moon.css
#
# This is the bug that we're describing.
reveal-init -f moon -d test_reveal/ my_slides

Environment

• Program version: master (after aa6eace), however this bug probably began to exist as soon as the -d option was added.

Possible remedies for the next version

• Don't check if the specified theme exists when -f is encountered. Instead, just read the value and check later i.e. after all command line arguments have been read.

Temporary solution for the filed version and earlier affecting versions (if any)

Always specify -d first before any other valid option.

[cszach]

Fixed (4f45198 & 0622595)