[p4] Slowdown and unquoted wildcard paths

[Weintraub, David]

Here's the note from Technote #19:
 
Wildcard expansion
On Windows the Perforce client executable performs wildcard expansion directly (via setargv.obj) rather than relying on the shell. While this works well with both the DOS box (which doesn't do wildcard expansion) and the MKS Korn Shell (which does), it means that to get a * past the Perforce client under the Korn Shell, you must quote it twice (i.e. '"*"'): once to get past the Korn Shell, and once to get past the wildcard expansion in the Perforce client. 

So, it appears that if I do:

    windows> p4 files */*/*

The Windows shell does not expand the "*" (just as expected), but then this is sent to setargv.obj, and expanded in there before the "files" command is executed. To prevent this, you need to do this:

    windows> p4 files "*/*/*"

Which does appears to be much faster on my system.

I guess the question is why would Perforce even bother to link setargv.obj to the p4 command line client since Perforce sub-commands (like "files" and "dirs") seems to have no problems directly handling the expansion in the first place.

Then again, this probably has nothing to do with P4V in the first place.

-----Original Message-----
From: perforce-user-bounces at perforce.com [mailto:perforce-user-bounces at perforce.com] On Behalf Of Shawn Hladky
Sent: Tuesday, June 06, 2006 10:28 AM
To: Javier Arevalo
Cc: perforce-user at perforce.com
Subject: Re: [p4] Slowdown and unquoted wildcard paths

On 6/6/06, Javier Arevalo <jare at pyrostudios.com> wrote:Shawn Hladky wrote:
> Hm... I don't believe that the windows command interpreter expands 
> wildcards. To my knowledge, neither command.com nor CMD.exe have ever 
> done anything like that.

You're right about the windows command shell.  I've been fooled by a number of utilities that all seem to work that way.  With a little research, I found that you can use a link option<http://msdn2.microsoft.com/en-US/library/8bch7bkk.aspx>on an exe to emulate this behavior (with VC++ cl.exe).  From the Jamrules file in the P4API, it appears that p4.exe is linked with this option, which explains its behavior at the command-line.

You should definitely be wary of the commands p4v shows you it's executing.
And not just b/c wildcard and space issues work differently.  P4V is doing a lot to maintain it's state as a full-fledged GUI, and not only executing the commands you think it should be.  I'm also suspicious that p4v is not showing every command it executes.

As a really bad example of drawing too much from the command output, I found a developer running a script that literally walked the tree to get a recursive file listing (p4 dirs + p4 fstat on every folder).  He figured out how to do it purely by watching the commands in P4Win as he expanded the tree.

On 6/6/06, Javier Arevalo <jare at pyrostudios.com> wrote:
>
> Shawn Hladky wrote:
> > I would be surprised if this problem were related to wildcard 
> > expansion.  At the command line, it's the windows command shell 
> > that's trying to expand the wildcard before passing on to the p4.exe...
>
> Hm... I don't believe that the windows command interpreter expands 
> wildcards. To my knowledge, neither command.com nor CMD.exe have ever 
> done anything like that.
>
> On the other hand, it's obvious that the P4V log is not a direct 
> reflection of what's happening under the hood, since it includes the 
> "p4" command (which wouldn't be part of API calls), and doesn't show 
> quotes in filenames that contain spaces.
>
> Ah well it was a nice try. These periodic slowdowns are starting to 
> annoy many people, and they turn to me in anger. ;)
>
> --
> Javier Arévalo
> Pyro Studios
> _______________________________________________
> perforce-user mailing list  -  perforce-user at perforce.com 
> http://maillist.perforce.com/mailman/listinfo/perforce-user
>
_______________________________________________
perforce-user mailing list  -  perforce-user at perforce.com http://maillist.perforce.com/mailman/listinfo/perforce-user