CheckTex utility script

[Andrei]

Considering the recent problem of missing textures fixed by [r937] and [r938], I decided to write a texture checking script.

It can be used simply by copying it next to the /data/ folder and running it, in which case it checks all .LEVEL files, but it also has finer options for specifying .LEVEL files individually and the data root directory (called "root directory" in script).

Options:

Option	Effect
-v	enable verbosity (default is silent except problems)
-r	set data root directory (default is "./data")
-s	set level scan directory (default is "./")

Example usage (outputs omitted):

$ ls
bin  checktex.sh  data  doc  src

$ ./checktex.sh
$ ./checktex.sh data/maps/alignster/alignster.level
$ ./checktex.sh --rootdir /c/alternative_data_folder/
$ ./checktex.sh --scandir data/events/01-triggercup/ --verbose

I've already run it for current [r941] and it was almost clean, except for this:

/c/WORKDIR/trigger-rally-0.6.6.1/data/maps/leaves/leaves.level
cannot find: /textures/sky/dark-blue.jpg

The script is attached to this post and will be uploaded to the devkit folder.

To those who are experienced with writing Linux shell scripts, let me know if you find mistakes or bashisms in CheckTex. Before I posted this, I've had difficulties with grep's regex.

[Andrei]

Version "2" is available with minor code quality improvements.

Changes:

• renamed --rootdir to --datadir to make its meaning more obvious: this option is used to specify where to look for textures (which aren't local to the map)
• removed --scandir and added ability to scan any number of given directories (see examples)

Example usage:

$ ls
bin  checktex.sh  data  doc  src

$ ./checktex.sh --verbose data/maps/old/ data/maps/alignster/alignster.level
DataDir=/c/WORKDIR/trigger-rally-0.6.6.1/data
data/maps/old/oldbis.level
data/maps/old/oldquinquies.level
data/maps/old/oldsexies.level
data/maps/alignster/alignster.level

Unless bugs are found or features requested, this one is hopefully the last version.

[Simone Weiss]

Hi,

I am not really super experienced with writing shell scripts in Linux but i anyway tested your script (version 2) on Debian: I noticed one thing.

When I just download your script and try to execute it the following error occurs:

bash: ./checktex.sh: /bin/sh^M: bad interpreter: No such file or directory

This should be caused by different line delimiters in Windows\r\n and Linux\n.

sed -i -e 's/\r$//' scriptname.sh

Fixed the issue for me and I could execute your script.

If there is an easy way to avoid this problem, maybe it could be changed in a newer version. Or if not maybe it should be added of to the documentation.

[Andrei]

@Simone: thanks. I didn't realize line endings could be a problem. I'll make sure my other scripts have LF line endings as well.

A new problem I found (it is annoying but not critical) is that the script fails to process file paths with spaces in them. For example if "data/maps/race 1/race 1.level" exists it will be processed as:

grep: ./data/maps/race: No such file or directory
grep: 1/race: No such file or directory
grep: 1.level: No such file or directory

I tried looking for solutions on StackOverflow but they were all nasty, like the saying "the cure is worse than the disease".

Attached is version 3 with Unix line endings.

[Onsemeliot]

the script fails to process file paths with spaces in them

This is normal behaviour in GNU/Linux but in my experience it is easy to deal with either by avoiding such path names (which I deliberately do) or by using quotes (in scripts) for strings that should be path names. But I guess you know that better than me anyway.

[Andrei]

or by using quotes (in scripts) for strings that should be path names

The problem is that adding quotes doesn't work in this case.

After I searched SO again I've seen two interesting possible solutions:

1. Use the IFS variable to ensure the separator is newline instead of space. link
2. Use the read program. link

Of course if there is a better way, I'd like to know.

I don't want to give the impression that I'm overestimating the worth of the CheckTex utility. This is more a case of wanting to perfect it as much as possible before never touching it again.

[Onsemeliot]

I totally get your approach. If it really is only needed for checking the textures it shouldn't pose a problem since I never use spaces in file or directory names. And as far as I know nobody else did that either so far.
We could introduce a policy that states our naming convention to prevent people from tying to do this in the future.

[Andrei]

Version 4 is available and this one can handle spaces in file paths.

It fixes a couple of mistakes and removes some bashisms from the previous version:

• changed $(pwd) to $PWD
• added double-quotes to certain variables, such as #@
• bashism removed: local variables
• bashism avoided: printf -v VAR
• bashism avoided: <<< "HereString"

There may still be "bashisms" that I missed.

Bashisms, (as they are described here), need to be avoided to keep the script compatible with Unix-like systems that don't use BASH. The benefit is better portability but the drawback is uglier code.

@Onsemeliot: do you need extra features or changes in CheckTex or is it sufficient as-is?

[Onsemeliot]

do you need extra features or changes in CheckTex or is it sufficient as-is?

Thank you, it's great. This way I discovered I used a wrong extension for the sky texture in the leaves map. (I corrected that in r943.)

Would it be easy to check if all codriver commands are covered by samples and icons also? In my experience it is much easier to overlook a misspelled codriver command because it gets ignored if there is no fitting audio file or icon for it. If I have a wrong texture it is most of the time very obvious and therefore hard to overlook.

[Andrei]

This way I discovered I used a wrong extension for the sky texture in the leaves map.

You may need to update the screenshot "ss.png" for it as well, if the new sky is different.

(I corrected that in r943.)

Formatting reminder: if you want to link to a revision, simply put it in square brackets: writing [r943] turns into [r943] automatically.

Would it be easy to check if all codriver commands are covered by samples and icons also?

Easy probably not, but I'll try it. Checking codriver notes is more complicated because there's extra processing involved: more combinations need to be checked in multiple sets of codriver voices and signs.

The attached version 5 of CheckTex is almost identical to the previous version, except it uses sed to clean up a variable of empty strings instead of checking for empty strings in a loop. To the user the difference should be non-existent but I'm attaching for testing purposes, just in case I messed something up.

EDIT: used sed -E instead of sed -r for portability.

[Onsemeliot]

You may need to update the screenshot "ss.png" for it as well, if the new sky is different.

I thought of that too but it's not that different. The sky is just a little darker. So I decided against updating it. I think this is neglectable because it would not cause the screenshot looking obviously different.

Formatting reminder

Thanks, I didn't know that.

The attached version 5 of CheckTex

I did use the verbose mode to see what it is doing and it looks fine to me. (Thanks to the previous version I corrected the original typing error already.)