Conversion from string to list in Prolog - bash

Question

I'm trying to use a piece of software and I'm running into some problems.
It's worth noting that using university computers which have prolog preinstalled(OSX) or Windows computers the same piece of software works. While it does not work on my Linux/Ubuntu machine.
The software starts up with a bash script using this form:
echo "reset_statistics(off), specific_load_predicate(filename), tokenize(\"$2\", List), tex(List, $3)." | ./prolog-executable
The prolog executable is created using swipl -c and qsave_program/1
Now I found out the predicate tokenize is of the form:
tokenize([A|As], List) :- ...
So it takes a list as input, but the bash script provides a String.
Is it possible using some sort of prolog module or extension that would automatically make the conversion from string to list? Because the same code works on other computers.

Answer 1

SWI-Prolog unfortunately deviates from the Prolog ISO standard in that what is surrounded by double quotes is no longer a list of character codes.
To restore the compliant behaviour in this respect, use one of the following methods:
invoke SWI-Prolog with the --traditional flag
add :- initialization(set_prolog_flag(double_quotes, codes)). to your source file.
add :- set_prolog_flag(double_quotes, codes). to your ~/.swiplrc initialization file.
In fact, instead of going with lists of character codes, I recommend you take a different route altogether and adapt your programs to use lists of characters, which means that each character is represented by an atom. This has the great advantage that toplevel answers remain very similar to what appears in queries, and are in fact quite readable by themselves. You obtain lists of characters for example by putting:
:- set_prolog_flag(double_quotes, chars).
in your ~/.swiplrc initialization file. With the value chars, you get for example:
?- Cs = "hello".
Cs = [h, e, l, l, o].
I recommend you use this value, and adapt your existing programs to work with lists of characters. Long-term, I think this will be the the best and most widely used approach, which was historically also what double-quotes were meant to denote.
Until we get (back) there, you can use one of the methods above (i.e., switch to codes as an intermediate solution, to at least work around the problems introduced by SWI 7), then adapt your libraries to work with codes and characters, and then, at last, switch to characters.