eduke32: (QOL) ignore case when check for user game data

[s1eve-mcdichae1]

...so shareware version is not downloaded unnecessarily, in case user has old DOS files in ALL CAPS. Add rename dependency. Modeled after wolf4sdl.

[s1eve-mcdichae1]

(Make $dest dir before pushd so rename is always safe.)

[joolswills]

Sorry, this reply is a few years late. I think I would prefer to just check for the file in caps as well, rather than renaming user data. I suppose a mixed case filename is possible, but I would think unlikely. Unless there is a specific release with mixed case, which we could handle.

[joolswills]

Thinking about it, the check could be modified to use find "$dest" -maxdepth 1 -iname "duke3d.grp" which would work without renaming perhaps.

[s1eve-mcdichae1]

Am I overthinking or does it need all this:

if [[ -z "$(find "$dest" -maxdepth 1 -iname duke3d.grp 2>/dev/null)" ]]; then

if [[ -z "$(find foo)" ]] because find always return true whether file is there or not, so if ! find will never work the way I think it should? So instead, have to do the find and test for nonzero string length.

Then 2>/dev/null because, if $dest not exist yet, then it return find: ‘foo’: No such file or directory, reads a nonzero string and makes the [[ -z foo ]] test think the file is there and then shouldn't be download?

Edit no this won't fail the download (I guess since it read stdin and not stderr) but still write error to screen (log?) if not suppress.

So, either suppress with 2>/dev/null or else, maybe just put the mkUserDir before and outside the if so that $dest will necessarily always exist?

[joolswills]

You can take advantage of the processing order of conditions:

eg.

if [[ ! -d "/doesnt/exist" || -z $(find /doesnt/exist -iname "somefile") ]]; then
  .. do something
fi

[joolswills]

Posted on mobile, and had typos - fixed them. But hopefully this gives an idea :-)

[joolswills]

Making the directory before also seems fine, and makes it simpler.

[joolswills]

Changes look good thanks - I just had a thought, technically if someone made a folder called duke3d.grp I think this would fail. I didn't think of it until now, but it's minor and unlikely! A -type f parameter would resolve it though.

[s1eve-mcdichae1]

technically if someone made a folder called duke3d.grp I think this would fail. I didn't think of it until now, but it's minor and unlikely! A -type f parameter would resolve it though.

if there is a folder there with that name, and this check fails, (ie. doesn't find a game data) then it tries to download shareware data and...what next?

Saves it to ports/duke3d/duke3d.grp/duke3d.grp right, which doesn't work anyway?

Edit no i don't know how it'll work with the unzip command:

unzip -L -o "$temp/dn3dsw13.shr" -d "$dest" duke3d.grp duke.rts

[joolswills]

It's not a likely scenario - someone would have to make that folder. But maybe worth adding the -type f to be sure.

[joolswills]

I think I missed your point - as even with the -type f, it would then not find the directory and try and unpack. and the unzip might fail. I guess this could happen in the old logic too. Your code is safer without the -type f so I'm going to merge.

[joolswills]

Thank you!

[s1eve-mcdichae1]

as even with the -type f, it would then not find the directory and try and unpack. and the unzip might fail.

Yeah that's what I was getting at. Cheers!

[joolswills]

Sorry about that 😄. Thanks for the PR!