0

I need to detect if a batch file has been executed from the local shell or by double-clicking within P4V. Is there a way I could check if P4V is open?

At first I thought to do it in this way, but as always, TIMTOWTDI. Any thoughts?

Samwise
  • 68,105
  • 3
  • 30
  • 44
John Doe
  • 1,058
  • 8
  • 30
  • 1
    When you say "from Perforce" do you mean as a custom tool in P4V, or as a trigger on the server, or as a P4EDITOR setting, or...? – Samwise Sep 11 '17 at 14:19
  • @SamStafford As a file. In the Depot view, I navigate to my batch file and double-click it. – John Doe Sep 11 '17 at 15:41
  • 1
    This sounds like it might be an [XY problem](https://meta.stackexchange.com/questions/66377/what-is-the-xy-problem). *Why* do you need to make a distinction between whether your script is run by a GUI or command-line interface? – jamesdlin Sep 11 '17 at 19:57
  • @jamesdlin To collect some informations about my files from the depot (like file versions). – John Doe Sep 12 '17 at 05:32
  • @jamesdlin you may be right about the `XY problem` – John Doe Sep 12 '17 at 05:36
  • If the purpose of your script is to collect information about Perforce files you might want to run it as a custom tool in P4V...? I'm actually not sure in this case how your Y is at all helpful to your X. :) – Samwise Sep 12 '17 at 07:17
  • @SamStafford The script is just a piece of the big cake. It'a a bigger script which launches all kind of tools and one of the tasks that it should do would be to collect the file versions – John Doe Sep 12 '17 at 07:31
  • @jamesdlin Check my solution which I posted as a comment to Sam's comment if you are interested. :) – John Doe Sep 12 '17 at 12:29
  • @JohnDoe You still haven't really explained *why* you care about distinguishing between running your script via command-line or via p4v. You say to collect some information about depot files: why does it matter what program invoked your script? The depot is the same! – jamesdlin Sep 12 '17 at 19:21
  • @jamesdlin I have different scenarios for running my script, when you run from `Perforce`, you are working with network, if you run it from the local machine, the informations from `Perforce` won't be collected and we assume you have only local workspace. – John Doe Sep 13 '17 at 07:00
  • @jamesdlin Additionally, there are two more possible scenarios, the script can be executed from other two versioning systems and different queries must be executed to collect the informations. I hope it's clearer now :) – John Doe Sep 13 '17 at 09:38
  • Personally I think the design sounds incredibly unintuitive (almost no programs behave differently based on what parent process executed them) and sounds rather brittle. IMO it would be more reasonable to behave different based on different environment variables, the current working directory, etc. – jamesdlin Sep 15 '17 at 10:41
  • @jamesdlin out of the box it may sound weird/unintuitive, but to make an ideea why is this needed, imagine you have a github project and assume that you want to have a version check on all the files of the project so you get a warning if you're not up to date. In 2 months half of your team decides that Perforce is better and they want to work in Perforce, and others want to work locally. You must have support for github and Perforce versioning and also local use case( this means different implementation for gathering this info), therefore you must make a decision based on the calling process. – John Doe Sep 15 '17 at 11:26

1 Answers1

1

Short answer: no, not really.

Long answer:

You can try to fake it, as you suggest, by checking for a running p4v.exe process. This will only tell you if P4V is open, though. If you had P4V open in another window, and you ran your batch file from a shell (e.g. double clicking in Explorer, or running it from a cmd prompt), you'll get a false positive.

Another approach you might take would be determining whether the script is within a Perforce client workspace. That could potentially be done by having the script run a "p4 where" on its own path to see if it's within the workspace -- but it depends on the script's executing environment having correct connection settings, which depends on the client machine being configured "nicely" (e.g. with P4CONFIG files and/or "p4 set", which are accessible to all Perforce client apps -- if you use P4V exclusively its connection settings won't be readily accessible to your script).

Samwise
  • 68,105
  • 3
  • 30
  • 44
  • Well, I finally came with a solution to get the PID of the parent process of the running script(which will return the PID of a cmd process). Then get the PID of the parent process of that cmd process, which is the real parent process of my script. Therefore, if the process name of the last collected PID is "p4v.exe", I am in Perforce scenario, otherwise, if the process name is "explorer.exe" I am running from local. – John Doe Sep 12 '17 at 11:50