| 8 years agoQAP commented on job000607 for[I reported this originally, and was involved in the investigation]
This doesn't seem like a P4Perl bug. The error is somewhere in the native P4 libra ...[I reported this originally, and was involved in the investigation]
This doesn't seem like a P4Perl bug. The error is somewhere in the native P4 library against which P4Perl links (and to which include\p4\runcmd.h corresponds).
To add detail: I hit the problem with filenames containing "(" and ";", each failing differently, but the shell being the culprit in both cases. I didn't hit the problem with filenames containing whitespace because of the above ("UNIX: quote with ' args with spaces, and use system()").
I never hit the problem (with the same files) on Windows. I believe the reason is that the shell never gets involved via CreateProcess() - not that "(" isn't a Windows metacharacter. (";" definitely is a Windows CMD metacharacter and I never had issues with ";" either.)
Suggested solutions:
PROPOSAL 1: You already handle spaces as special ("UNIX: quote with ' args with spaces, and use system()"). Do the same with the other shell metacharacters. I.e. if the filename contains ";", it must be quoted too.
PROPOSAL 2: Use execve (or friends) instead of system. That allows you to specify the parameters as an array, and the shell doesn't get involved. « | |
| 9 years agoQAP created job000426 for perforce-software-p4api-net:When connecting, one can specify either (A) the current working directory or (B) the [port, client, user, password] quadruple, but not both.
As a res...ult, it's not currently possible to implement the equivalent of the following command-line using P4API.NET:
set P4CONFIG=p4config.txt
echo P4USER=bdylan > /some/path/p4config.txt
p4 -d /some/path -c myClient [COMMAND]
which would result in:
* P4USER = bdylan (set via P4CONFIG)
* P4CLIENT = myClient (set via command-line switch)
See https://swarm.workshop.perforce.com/files/guest/perforce_software/p4api.net/p4api.net/Connection.cs method Connect(), the "if" block starting at line 223.
In P4API.NET, I can call:
(A) Connection.Connect(new Options { "cwd" : "/some/path" }) in which case I'll run with the CurrentWorkingDirectory set to /some/path, will find the p4config.txt file in that directory, and will set P4USER to bdylan. I can't specify the client/user/password unless I put them into the config file. (This uses the 1-parameter P4Server constructor.)
(B) Connection.Connect(null) in which case I'll make use of the Server/UserName/Client that I've set up. However, in this case I won't find p4config.txt. (This uses the 4-parameter P4Server constructor.)
It would be nice to allow utilising both (A) the "cwd" and (B) the Server/UserName/Client properties. In fact, there already is a 5-parameter P4Server constructor that could be used for this so this may not be too complicated... « | |
| 9 years agoQAP created job000425 for perforce-software-p4api-net:We're new to using P4API.NET, and we've found one aspect particularly confusing: the lifecycle of a Connection and its private P4Server object.
1)... Naming confusion.
Semantically, the Connection class represents a "connector" rather than a connection (it can connect and disconnect), while the P4Server object represents the connection. The naming is rather confusing.
--------
2) Phantom events.
There are various events defined on the Connection class (CommandEcho, ErrorReceived, InfoResultsReceived, TaggedOutputReceived, TextResultsReceived) but this is a little illusory ("phantom" events): the events are really on the P4Server object. Consider these:
* you subscribe to CommandEcho before Connect()ing and you get a NullReferenceException because there's no underlying P4Server object yet
* OK, so you Connect() first, then subscribe to CommandEcho; then you Disconnect() and Connect() again and - guess what - your subscription has been lost
--------
3) Phantom property: CommandTimeout
Same as above: setting Connection.CommandTimeout before Connect() throws a NullReferenceException.
--------
4) Ineffective (and inconsistent) property: CurrentWorkingDirectory
Similar to CommandTimeout, setting Connection.CurrentWorkingDirectory is completely ineffective before Connect(). However, unlike in the cases above, calling it before Connect() does *not* throw. It just does nothing. This is not only confusing, but it's also inconsistent with the behaviour of the other "phantom" events/properties above.
--------
In all of 2), 3), 4), one must be familiar with the internals of Connection to be able to use it. Specifically, one must know that all these events and properties are passed through to the private (!) _p4server field, and also that the field is disposed in Disconnect().
AFAICT, all this is undocumented. « | |
