Weird fallback mechanism for input data in python scripts
Hi All,
I found some unexpected behaviour with inkex-based extensions if a non-existent SVG filename is specified.
To reproduce:
cd share/extensions ./gimp_xcf.py non-existent-file.svg
Expected behaviour:
* Script exits with an error message "Unable to open non-existent-file.svg"
Actual behaviour:
* Script silently falls back to reading from standard input, and appears to freeze.
This appears to be caused by the fallback mechanism for obtaining data streams in the Effect.parse() function in inkex.py. At the moment, it does this:
1. Try to read file specified as a function argument e.g., my_effect.parse("this-file.svg) 2. If that file can't be opened, try to read the file specified in self.svg_file 3. If that file can't be opened, read from stdin
This could lead to some weirdness e.g.,
e = ProcessImportantData()
# Specify the wrong file name somewhere e.svg_file = "wrong-input-data.svg"
# Later, try to read from the correct file, but with a typo e.parse("correct-input-data-with-typo.svg_BORK")
# When we apply the effect, the "correct-input-data-with-typo.svg_BORK" file doesn't exist, and the script will silently fall back to using the wrong data file. e.effect()
I have attached a patch that changes the behaviour so that the same order of precedence is maintained, but the script will fail if the specified file cannot be opened. I'm not the best Python programmer, and I don't know the precise intended behaviour of the extensions system, so please could someone review/comment?
AV
participants (1)
-
Alex Valavanis