Scipion fails when the filemane has " - "

[pconesa]

It is interpreted a a parameter in xmipp programs and may be others

Possible solutions:

escape special characters
pass file names as between ""
...

[yaizar]

Which filename?

[yaizar]

OK I missed the space around the -, got it

[yaizar]

@cossorzano can you give me more details on this? I'm not able to reproduce:

[pconesa]

@yaizar , this fails when using the file un an xmipp protocol...try a movie alignment after import.

[cossorzano]

It fails when after importing you try to do correlation alignment

[yaizar]

So I've fixed it for both correlation and optical alignment, BUT! If we wanna use xmipp picking next, the picker doesn't launch. I get a window saying:
SEVERE: No enum constant xmipp.viewer.particlepicker.training.model.Mode.
and a veeeery long list of warnings and errors that prevent the picker from opening (see picture below). At this point it's hard to continue fixing paths in commands, because we use the micrographs.sqlite to launch the picker with this command:

java -Xmx2g -d64 -Djava.library.path=/home/yaiza/scipion/scipion/software/em/xmipp/lib -Dplugins.dir=/home/yaiza/scipion/scipion/software/em/xmipp/external/imagej/plugins -cp /usr/lib/jvm/java-8-openjdk-amd64/lib/*:/home/yaiza/scipion/scipion/software/em/xmipp/external/imagej/*:/home/yaiza/scipion/scipion/software/em/xmipp/java/lib/* xmipp.viewer.particlepicker.training.SupervisedPickerRunner --input "Runs/000381_XmippProtOFAlignment/micrographs.sqlite" --output "Runs/000449_XmippProtParticlePicking/extra" --scipion 59375

Whatever follows is xmipp's dark magic failing to read filenames with spaces. Errors will likely happen with a good bunch of protocols that need those filenames as arguments for their command line calls (hard to find how many of them, probably mostly xmipp but others potentially too).

So! I think it is in everyone's interest to avoid filenames with spaces :) If the space is in the folder we aren't even able to import anything as of now. Anyone against having a space-in-filename validation and warning at the very beginning?

[delarosatrevin]

Hi all,

I'm a bit lost with this issue, starting with its title, that is very generic.

First, I agree that suggesting users to avoid spaces in filenames is a good practices. Nonetheless, we should try to be as robust as possible. It can be annoying if someone has its filenames (or folders) with some spaces and then needs to rename everything.

Apart from that, it would be good to localize where we are affected by this problem.
In some cases in the past, it was when (from a Scipion protocol) we were passing the filenames without the surrounding quotes. In this case I would said that we should try to encourage to always use double quotes around filenames when preparing command lines in protocols.

The other big source of problems is when the programs does not accept spaces. In most cases, we do not have control over the programs and their code...so either it will fail...or we could create links (without spaces) for them to work. This is seems a lot of extra work and code. In the particular case of Xmipp, I think we should try to prepare the programs to receive as inputs filenames with spaces. Not only from Scipion, but also the user could execute the programs from the command line.

[yaizar]

I'm gonna follow @josuegbl 's advice and remove the spaces when we create the file copies/symlinks at the very beginning (I wasn't aware of those! minimum amount of code & fixes most problems :) ). I'll look a bit into the white spaces in the folder name, but I think this is a different issue that's most likely gonna remain for now. EDIT: No issues with white spaces in folder name unless space is trailing space, which mine accidentally was, so this is good to go.