If I debug a command line app from Xcode, I get a different $PATH than if I run the same app from a terminal session.
For example, when run from a Terminal:
$env | grep "PATH="
//output: PATH=/opt/local/bin:/opt/local/sbin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin
...
From an Xcode debug session:
let environment = ProcessInfo.processInfo.environment
print(environment["PATH"] ?? "No PATH found")
//output: /Applications/Xcode.app/Contents/Developer/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin
As a result, some command line apps are unavailable while debugging.
How do I get the terminal window $PATH environment variable within an Xcode debugging session?
As Martin R said in his comment, the environment passed to GUI programs is different than that used by shell applications.
I never found a simple solution to the problem. I suspect that the environment paths are set either with launchctl or a default is provided to GUI apps.
Finally, I ended up changing the environment used by class Process (Swift). Though not perfect (and certainly more complicated than I'd hoped), it works. You can find the entire implementation I used at: GitHub
Related
yesterday I had SumatraPDF and VisualStudioCode with latex-workshop working with forward and reverse-search. Today the reverse-search didn't work any more. With a simple bat file I tried to show the commandline arguments.
echo %*
pause
They seemed correct and when I copied the command and paste it into a new cmd it works. To do further testing I tried to direct command and run it.
"C:\....\Code.exe" -g "%1:%2"
pause
Visual Studio Code responds: bad option -g
In SumatraPDF I set cmd as command.
Now the behavior is that I have two cmd windows. With the cmd directly opened the VSC open's the file. With the cmd launched indirect I got the error message.
I have tried resetting the environment variables, changing the current working directory, and checking the code page currently in use.
How can it be that cmd behaves differently with seemingly the same environment? And what can I do to make a cmd started from an application work like a cmd started by windows?
Update: It appears there were a couple of recent security changes in the way VSCODE.exe is allowed to interact with the command line (especially affecting LaTeX-workshop users) so for recent changes twice this year see the discussion at https://forum.sumatrapdfreader.org/t/inverse-search-not-performed-for-vs-code-exe/4486/27
Within SumatraPDF the reverse syntex command for %1 is replaced by %f for file and (l)L for line
It is triggered by a double click near the line of interest and if the synctex index file was compiled correctly by PdfLaTeX (or similar) it will include the tex %f(ilename) and the nearest %l(ine) reference to the point where double clicked.
Thus your tex syctex enhanced "reverse search" call out of SumatraPDF should historically be
"C:\...path to...\Code.exe" -g "%f:%l"
that's Lower L not 1
Avoid using any depreciated -inverse-search parameter from a LaTeX editor just add it once into SumatraPDF-settings.txt and then it's not disturbed by repeated assignments when running your -forward-search.
It will NOT work if the file.synctex or file.synctex.gz is corrupt by a bad PDF compilation.
HOWEVER It seem Microsoft have added the requirement to add a CLI.js handler and requires another switch setting after that ! (see link to discussion in Update above)
For a small test file download https://github.com/GitHubRulesOK/MyNotes/raw/master/AppNotes/SumatraPDF/LATeX%20and%20Reverse-Search.zip unpack and open sync.pdf in SumatraPDF to test that double click on page opens sync.tex in the editor
If the message is cannot start ... then the command line is not configured correctly. A rough test for a bad synctex is to see what happens if the call is changed by adding cmd /k echo to the start, since that will confirm the reverse command. Here I wrote "wrong" as the path to code.exe, once corrected I can remove cmd /k echo.
For some other systems where the reverse might change
see https://github.com/sumatrapdfreader/sumatrapdf/issues/1197#
However there should be no interference in a valid VsCode call.
I'm building a CLI tool as a Swift Package. Part of the process requires me to invoke some processes (such as gsutil). When I try to invoke those, I always end up with
*** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: 'launch path not accessible'
Some further analysis revealed that regular commands suchs as pwd or which work just fine. As pictured below, if I try to echo $PATH, I get an incomplete result.
The value of $PATH while running the project directly
/Applications/Xcode-beta.app/Contents/Developer/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin\n
is completely different from my actual $PATH variable:
echo $PATH
/Users/skwiggs/google-cloud-sdk/bin:/Users/skwiggs/.npm-global/bin:/Users/skwiggs/.rbenv/bin:/Users/skwiggs/.rbenv/shims:/Users/skwiggs/google-cloud-sdk/bin:/Users/skwiggs/.npm-global/bin:/Users/skwiggs/.rbenv/bin:/Users/skwiggs/.rbenv/shims:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/share/dotnet:~/.dotnet/tools:/Library/Apple/usr/bin:/Library/Frameworks/Mono.framework/Versions/Current/Commands
How can I ensure that my env variables are correctly set while debugging my CLI tool?
Running the tool directly from a shell will pass it the expected $PATH value, so this issue only happens when debugging.
If you want to debug your program with the correct $PATH value, you can add an Environment Variable in the active scheme. That variable is only used while debugging, so it's safe to override it (it will be ignored when invoking your product from a shell).
Open a terminal
Run echo $PATH
Copy the output
Then, open XCode
Scheme -> Edit Scheme -> Run -> Environment Variables -> Add.
Name PATH Value <paste the value from terminal>
Build & run, you can now debug as if your project was invoked from a shell.
(keep in mind you'll have to do this for every new project where this behaviour is needed, and any change to your $PATH will have to be retrofitted to your projects)
If you're using Swift, you can access your environment variables directly using
guard let path = ProcessInfo.processInfo.environment["PATH"] else {
return
}
// ...
I changed the environmental variable LD_LIBRARY_PATH from the Ubuntu terminal (because I was receiving an error) and the changes were applied when I ran code (a Python code) from the terminal. But when I ran the same script from the Visual Studio Code, the error remains. How to update the environmental variable so that Visual Studio Code sees it, as well?
Environment variables are passed from parent process to child process; they are not (say) global to the system or the user. If you change a variable in one shell, the change is only seen in that shell and any processes started from that shell. So the simplest solution is to change the variable and then start VSCode from that same shell:
$ export LD_LIBRARY_PATH=/some/useful/path
$ code
If you want to keep using that shell for other things, run it in the background:
$ code >/dev/null 2>&1 &
The redirection to /dev/null is needed because otherwise VSCode prints logging information periodically, and that output will be mixed with whatever else you're doing.
If you want to set the variable permanently, see the question How do I set a user environment variable? (permanently, not session). After following those instructions, you'll need to start a new shell (and possibly even logout and login) first so the settings take effect. Then launch VSCode from the new shell.
I need a way to open a file in a Metro app from command line.
So far I've figured out how to start the app from command line without any third-party scripts
explorer shell:AppsFolder\Microsoft.Reader_8wekyb3d8bbwe!Microsoft.Reader
but I haven't been able to figure out how to include a file name yet.
Launching
explorer shell:AppsFolder\Microsoft.Reader_8wekyb3d8bbwe!Microsoft.Reader example.pdf
just opens up a default explorer window.
Any idea from Windows 8 experts on how to accomplish this without any third-party tools/cmdlets/etc.?
Note: In fact I'm using Windows 10 but I guess if there's a Windows 8 / 8.1 way to do it, it'll work for 10, too.
If you're still looking for the answer, the best way to open a file in a metro app is to use an execution string like a normal app protocol does. The execution string looks like this:
bingnews:[arguments, can be left blank.]
microsoftvideo:[arguments, can be left blank.]
netflix:[arguments, can be left blank.]
So, to start up netflix, it's as simple as typing in Start netflix: into the command line.
To find the execution string for an app, go here: Control Panel\Programs\Default Programs\Set Associations
More info and examples can be found here.
http://windowsitpro.com/windows-8/opening-windows-8-apps-command-prompt-or-script
http://www.itsjustwhatever.com/2012/10/28/launch-windows-8-metro-apps-from-a-desktop-shortcut-or-command-line/
PLEASE NOTE: To open an app WITHOUT A PROTOCOL (One not listed in the registry or under "Set Associations") use OP's method:
explorer shell:AppsFolder\[appuid]![appfullname]
The app UID is the folder name without the version number. For example,
4DF9E0F8.Netflix_2.11.0.8_x64__mcm4njqhnhss8
becomes
4DF9E0F8.Netflix_mcm4njqhnhss8
The app fullname is the [App author].[App name] For example, 4DF9E0F8.Netflix. 4DF9E0F8 is the author, and Netflix is the name.
Put it all together to get
explorer shell:AppsFolder\4DF9E0F8.Netflix_mcm4njqhnhss8!4DF9E0F8.Netflix
Store Apps can only be started by the shell. So try this:
explorer.exe shell:AppsFolder\Microsoft.WindowsAlarms_8wekyb3d8bbwe!App
Or from run (Win+R):
shell:AppsFolder\Microsoft.WindowsAlarms_8wekyb3d8bbwe!App
If the app is the default handler then you can just launch the file or protocol. There isn't a good in-box way to launch a file into a non-default handler from the command line.
Windows Store apps aren't designed to run from the command line and there isn't a straightforward way to launch them from the command line. Apps which handle specific files or protocols receive them through FileActivatedEventArgs or ProtocolActivatedEventArgs rather than command line arguments
You could write a launcher app which uses CLSID_ApplicationActivationManager's IApplicationActivationManager to ActivateForFile a specific app.
The best way I've found to pass command-line arguments to the executable targeted by the shell command is via the Windows start command.
Using your example, you would end up with this:
start "" shell:AppsFolder\Microsoft.Reader_8wekyb3d8bbwe!Microsoft.Reader example.pdf
I don't have Microsoft.Reader installed, so I can't test that. However, I can verify that this pattern works with Windows Terminal. In this case, I pass it a command-line argument to tell it which profile I want to open.
start "" shell:AppsFolder\Microsoft.WindowsTerminal_8wekyb3d8bbwe!App new-tab -p "GitBash"
The first argument to the start command here — the empty string — is just the title of the window.
You can also pair this with cmd /c, which I've found is necessary for some launcher applications, such as my personal favorite, SlickRun:
cmd /c start "" shell:AppsFolder\Microsoft.WindowsTerminal_8wekyb3d8bbwe!App new-tab -p "GitBash"
I have a blog post with more info on running Modern apps from the command line, which you might find helpful in constructing these ridiculously obtuse commands.
Not sure if it works on Windows 8, but on Windows 10 I use this:
cmd /C start <app-name>:
For example, to start Slack:
cmd /C start slack:
I'm having this weird situation :
My user's and system's PATH variable is different than the PATH in powershell.
When I do :
PS C:\$env:path
C:\Windows\System32\WindowsPowerShell\v1.0\;c:\oldpath
However this is not correct, it looks like it stuck on some old PATH variable of my system, so none of the udpates I've done on it didn't change this variable (I do restart after every change to test).
Why is this happening? Do I have to set a PATH variable just for powershell?
The change might be "delayed", so try one or more of these solutions:
Log off and on again;
Task Manager > Restart "Windows Explorer" (explorer.exe)
Restart your launcher app (launchy, SlickRun, etc)
Reboot
Explanation:
Powershell will inherit the environment of the process that launched it (which depends on how you launch it). This is usually the interactive shell (explorer.exe). When you modify the environment from computer properties, you modify the environment of explorer.exe, so if you launch powershell from explorer.exe, (for example from the start menu) you should see the new environment.
However, if you launch it from something else (say a cmd.exe shell that you already had opened), then you won't since that process was launched under the old environment.
In other words: be careful how you are launching things.
In my case, I installed an app that incorrectly added itself to the PATH by creating a powershell profile that would override $env:PATH and blow out the existing configuration every time I started powershell.
Check if you have profile at USER\Documents\WindowsPowerShell\Microsoft.PowerShell_profile.ps1 and if it's doing anything fishy like setting $env:PATH.