Wildcards in command line

[sherpya]

(jrthwk)

Mplayer 36279 still don't work with wildcards. My attempts to play all files in some catalog with '.mp3', '.' or '' ended only one result - mplayer playing one or two files, and moreover - in catalogue where lie 19 mp3 file named 01.mp3, 02.mp3 and so on, mplayer was play files 19.mp3 then 18.mp3 and exit.
Latest build that correctly work with wildcards was 34401, build 35968 also have this bug.

[sherpya]

(P. N.)

I came here to post this exact bug. There is something seriously messed up with wildcards not only when trying to play local files but in URLs as well.

For example, try "mplayer http://blabla/?foo" and see that mplayer ignores completely the parameter and just dumps the help screen.

This has to be a problem with the Sherpya builds since other windows builds (SVN-35923-4.6.1 built on Feb 24, 2013" works OK.

Thanks again for the program!

[sherpya]

windows cmd does not provide globbing, the glob is delegated to the application, so I've hooked my code in mplayer playlist add part.
I need to decide if glob or not a command line, my current code was wrong because tries to glob http://etc, the idea is glob only if the path is a local path and the command line has * or ?, I've corrected the code to avoid globbing if : is found in command line after position 2 (i.e. a: is a local path), I still can't reproduce jrthwk problem, I can play 01.mp3 with the old code passing *.mp3 or ??.mp3

[sherpya]

(P. N.)

To reproduce the problem for local files, do this:

• Create multiple blank files "01", "02", "03", "04", "05", "06", "07", "08".
• Run "mplayer 0*".
• mplayer then tries to play "08", then "07" and then it exits with "(end of file)."

[sherpya]

it should be fixed with r36295+g2976e2a, please report

[sherpya]

(P. N.)

Well, sort of.

"mplayer 0*" in the local directory now works (and well done for that).
"mplayer http://blablabla?foo" for URLs now works (and well done for that too).

However:

"mplayer X:\*.mp3" does NOT work as intended. mplayer correctly identifies all files but it exits with multiple "File not found" errors. Probably, the reason is that in the case of drive letter wildcards, each expanded filename should be preceded by the drive letter. So, the expanded command line should be "mplayer X:\01.mp3 X:\02.mp3 X:\03.mp3" and so on...

[sherpya]

(jrthwk)

Good, all works almost as it must. Thanks.

About bug founded by P. N. - confirmed.
Mplayer unpacked in directory D:\mplayer, 5 mp3's (01.mp3--05.mp3) lies in directory D:\mp3\1\

If we stand in any directory except D:\mp3\1 and run D:\mplayer\mplayer.exe D:\mp3\1* or D:\mplayer\mplayer.exe D:\mp3\1*.mp3 - mplayer exit with multiple "File not found" errors.

If we stand in directory D:\mp3\1\ and run same command - mplayer work's fine and plays all files in directory.

[sherpya]

yes it's not really a full glob replacement, I'll try to add one when I'll find a good implementation around

[sherpya]

(Aaron)

Gianluigi, I'm not sure if this would be of any help, but may provide information (that you might already have): https://svn.code.sf.net/p/mingw-w64/code/trunk/mingw-w64-crt/crt/wildcard.c and https://svn.code.sf.net/p/mingw-w64/code/trunk/mingw-w64-crt/crt/CRT_glob.c

If you're already doing this, I apologize for suggesting otherwise, but it appears that including CRT_glob.o, rather than CRT_noglob.o will turn over CLI globbing to M$'s globbing code, rather than having to make your own, at least for local files.

Just a possible lead on getting this working the way you/we want it to, hopefully.