Re: [AD] New BeOS patch + problem with multi-line strings in config

[Stepan Roh <stepan@xxxxxxxxxx>]

On Sat, 17 Feb 2001, Angelo Mottola wrote:

> > What about adding of
> > something like converting "escape" sequences ('\n', '\r', ... or even '\'
> > on end-of-line ('\<eol>')). Is it wanted feature? It could be good,
> > especially with '\<eol>' sequence, but it would break backward
> > compatibility. There could be also some problems if anyone is finding
> > lines by brutal search for new line character, but I did not find it in
> > config.c. destroy_config() should be rewritten to store values with
> > escaping those characters. What do you think?
>
> Hummm... Using escape sequences may be a solution, but IMHO I think it's
> better to fall back on the single line implementation and convert the window
> close message into a single line statement. This is not only because it saves
> time, but because as you say adding multi line support to the config routines
> may break compatibility, and adds more overhead.

That's not as much overhead. It can be done on a few lines and will not
slow down config files handling. But yes, it will break backward
compatibility. I want to have this config files functions rewritten (it
could be backward-compatible by detecting some kind of '##$NEWFORMAT$' on
first line of config file). But it seems that I'm the only one :-( In
present version, you can't have config value which begins with whitespace
(it's auto stripped), you can't have multi-line strings, you can't have
arguments shifted ('%$1' format sequences). It can't be used for
translations of anything other than Allegro core library itself, it's
almost unusable for any game or program. There is also a security problem,
that user can pass it's own language.dat (or directly language config)
file to setuid Allegro program. But that's sysadmin's problem, if he is as
stupid (it's OK to that at home, but in shared environment it should be
considered evil) and of course problem with svgalib and DGA.

> > And I almost forgot: Would not it be good to have language.dat and
> > keyboard.dat unpacked in some CVS directory like resources/language and
> > resources/keyboard (to be able to diff them like any other file) and have
> > some script to update theirs *.dat after each commit (or before
> > releasing a WIP)?
>
> That would be really useful to keep translations up to date! The .dat
> creation could be added into zipup.sh. Can someone do this please?

Untested code below could do that. Those *.dat files should be unpacked to
resources/keyboard and resource/language directories respectively before
use of this :-) Dat utility must be present on target computer.

---diff start---

--- zipup.sh.old        Sat Feb 17 13:45:57 2001
+++ zipup.sh    Sat Feb 17 13:46:22 2001
@@ -193,6 +193,16 @@
 rm _tmpdoc.c _makedoc.exe


+# Create language.dat and keyboard.dat from resources directory.
+echo "Creating keyboard.dat..."
+
+(cd resources/keyboard; dat -a ../../keyboard.dat *.cfg)
+
+echo "Creating keyboard.dat..."
+
+(cd resources/language; dat -a ../../language.dat *.cfg)
+
+
 # convert files to djgpp format for distribution
 run_batch_file fixdjgpp.bat

---diff end---

BTW, in keyboard.dat, orig name of SK_CFG is /home/gfoot/tmp/sk.cfg, which
makes it hard to extract with dat utility. Some option should be added to
the dat utility to save objects to only file name portion of theirs orig
name (strip leading directories from orig name).

Have a nice day.

Stepan Roh