Not detecting P4CONFIG nor .p4config, ability to using Settings to force it would have helped

[nathan3700]

I'm using vs-code over Remote SSH. I cannot coax this extension into finding the p4 executable nor environment variables even though I can clearly see them in a tcsh TERMINAL opened to the remote host. In a tcsh term opened from within vs-code the .cshrc is such that it ensures p4 is in PATH and P4CONFIG is set, yet the extension behaves as if it is not.

I can coerce the extension into almost working bey forcing overrides in Settings for Port, User, and Command.

But I cannot force it to find our projects .p4config (I put it there for it to find, and it did not find it) and I cannot get it to expand P4CONFIG either. If I could have forced something in Settings maybe I could get farther.

Redacted output:

Performing one-time registration of perforce commands
==============================
Workspace folders changed. Starting initialisation.

Workspaces were added
> file:///some_path: Trying to initialise SCM Providers in this workspace.
	Note: the following overrides apply in this workspace:
		perforce.port: some_machine:1712	(!OVERRIDE!)
		perforce.user: napeirce	(!OVERRIDE!)
		perforce.client: none	(will not override)
		perforce.dir: none	(will not override)
	Explicit overrides may prevent auto-detection of other perforce client workspaces
Looking for a client root using the workspace root directory
some_path: /tool/pandora64/bin/p4 '-u' 'napeirce' '-p' 'some_machine:1712' 'info'
> file:///some_path: Found workspace using root directory
  * VS Code workspace root directory :
	Client name: some_machine
	Client root: <generic path that shows that it did not read P4CONFIG>
	User name: napeirce
	Server address: some_machine:1712
!!	Folder IS NOT in client root - IGNORING THIS CLIENT
> file:///some_path: Looking for perforce config files
some_path: /tool/pandora64/bin/p4 '-u' 'napeirce' '-p' 'some_machine:1712' 'set' '-q'
> file:///some_path: Did NOT find a valid P4CONFIG setting.
!!! IMPORTANT !!!
Previously, if no P4CONFIG setting was found, the extension would look for files name .p4config and parse them.
This is no longer the case. If you use p4config files, Please set your P4CONFIG setting and restart,
Either via environment variables or p4 set, e.g.:
		p4 set P4CONFIG=.p4config
!!! IMPORTANT !!!

> file:///some_path: Found 0 config file(s)
> file:///some_path: Finding client roots using each file's directory
> file:///some_path: Found the following roots from the location of 0 P4CONFIG file(s):

> file:///some_path: NO valid perforce clients found in this directory.
If you were expecting a valid client to be found:
  * Check if you can run perforce commands in this directory from the command line.
  * Look at the perforce commands above, see if they match your expectations and can be run in the directory shown.
  * Review your override settings in vscode, perforce.port, perforce.user, perforce.client, perforce.dir
    * you may need to set or unset them appropriately
> file:///some_path: To FORCE activation for the client 'some_machine':
	set perforce.activationMode to always.
This should allow you to view and manage changelists in that client, but is unlikely to be useful for files in this workspace

Initialisation finished
==============================

...
!!	Folder IS NOT in client root - IGNORING THIS CLIENT
	>>> P4CONFIG : NOT creating an SCM provider

[maciejmatczak]

I started to notice the same thing. New host, had to make same setup and I can't figure out why extension stopped seeing my user environment.

That sounds like the difference. Extension cannot see my environment from .bashrc file. Maybe something changes in Remote SSH envs?

[maciejmatczak]

@nathan3700, you might try debugging your environment setup with similar command that VS Code Remote SSH uses:

"C:\WINDOWS\System32\OpenSSH\ssh.exe" -T de02odcvde1440 bash

I was trying to find what differences I introduced between old and new env. Debug your printenv output.

In my case, it was too early .bashrc bail out in form of:

[[ "$-" != *i* ]] && return

... which effectively means I skipped the P4 setup for non-interactive sessions entirely.

[mjcrouch]

thanks @maciejmatczak - that's useful info as these kind of shell issues seem to be some of the most common ones people have, but they generally seem to be very environment-specific and hard to debug / reproduce