[Not GZDoom] [4.5.0 debian] -file no longer works with wildcards

[Matt]

In the previous release it was possible to do something like "gzdoom -file xxx/yyy/*" and load everything inside the yyy subfolder. Trying to do so now no longer loads anything.

[m8f]

Hmmm. Works for me:

Code: Select all • Expand view

.-(~/Games)-
`--> gzdoom -file doom/guncaster-sunlust/*
GZDoom g4.5.0 - 2020-10-31 10:07:33 +0100 - SDL version
Compiled on Nov  1 2020

M_LoadDefaults: Load system defaults.
W_Init: Init WADfiles.
 adding /opt/gzdoom/gzdoom.pk3, 630 lumps
 adding /opt/gzdoom/game_support.pk3, 2512 lumps
 adding /home/allkromm/Games/doom/iwads/DOOM2.WAD, 2919 lumps
 adding doom/guncaster-sunlust/Guncaster.pk3, 5993 lumps
 adding doom/guncaster-sunlust/precise-crosshair-v1.4.1.pk3, 24 lumps
 adding doom/guncaster-sunlust/sunlust.wad, 2788 lumps
I_Init: Setting up machine state.
CPU Vendor ID: AuthenticAMD
...

[Chris]

Wildcard patterns are generally handled by the shell. Your shell finds all files matching xxx/yyy/* and puts them in-place of the pattern as individual arguments to the process. The app itself never sees the wildcard pattern, unless it was escaped with the appropriate quote or backslash characters to prevent the shell from expanding it.

[Rachael]

Wildcard patterns are generally handled by the shell. Your shell finds all files matching xxx/yyy/* and puts them in-place of the pattern as individual arguments to the process. The app itself never sees the wildcard pattern, unless it was escaped with the appropriate quote or backslash characters to prevent the shell from expanding it.

Really? I did not know that.

But that begs the question:

Why is it working fine for m8f and not for Matt? The only reason I can think of is one of them is not using the same shell as the other. (Bash is the standard for Linux but I am curious to see if either of them have changed it)

[Matt]

It seems to be a problem in a Bash script I'm using. I have no idea what, though - it works for some folders and not others and I don't see any rational pattern to it, but it's clearly not GZDoom so this can be closed.

[Caligari87]

Check if your not-working paths have spaces in them. I have a bash launcher script for HD that gave me lots of "random" problems until I figured out it wasn't passing spaces correctly.

Of course, being a shell script neophyte I simply stopped putting spaces in my file/folder names instead of figuring out the arcane ritual required to escape them properly

[Matt]

It wasn't spaces, it's like

~/doom/da/goths/ which includes HorrorMovieGuy's goth reskin plus a textures pack
~/doom/da/ which contains mostly gameplay and aesthetic mods

If my script says something like "gzdoom -file da/blahblah.pk3" it's fine
If my script says something like "gzdoom -file da/goths/blahblah.pk3" it's fine
If my script says something like "gzdoom -file da/goths/*" it's bad
If my script says something like "gzdoom -file doom/da/goths/*" it's fine
If my script says something like "gzdoom -file doom/da/blahblah.pk3" it's bad

And I have no idea why.

Maybe the wildcard somehow makes bash start looking from the home folder or something?

[Chris]

Maybe the wildcard somehow makes bash start looking from the home folder or something?

It works from the current working directory. So if you're in or cd'd to a directory where da/goths/ doesn't exist relative to it, the shell won't be able to find any files to expand (and may then just pass it as-is to the app, which likely doesn't do file matching/deglobing, so it's a non-existent filename). The da/goths/blahblah.pk3 file could work if GZDoom looks for the given name relative to all the configured wad paths and it happens to be in one.