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.
Related
My question is whether it is possible to edit the crontab of a WSL2-based instance of Ubuntu with my Windows VSCode that is connected via WSL remote SSH.
If I type export EDITOR=code inside my WSL instance and then crontab -e, I am able to see a /tmp/crontab.sygFAU file load inside my VSCode instance.
The problem is that once I make edits to this file, it will save the file to /tmp/crontab.sysFAU but it doesn't actually take the next step of replacing the the real crontab file in /var/spool/cron/crontabs.
So once I re-open the crontab, it will just show what I had previously, and not my saved edits.
It would be nice to know if this is not possible or if there are any alternative ways to run a GUI editor because using nano is a pain!
An interesting question that I haven't considered before, myself. Here's what's happening:
You set your editor to code
You crontab -e, which properly loads VSCode with the temporary crontab.
However, because this is a Windows GUI application, it returns control to the parent Linux application (crontab) immediately after starting VSCode. You can see the same result if you just start notepad.exe from your shell in WSL -- Once Notepad starts (rather than exits) control is returned to the shell.
If you switch back to your terminal at this point, you'll see that crontab detected that the editor that it launched exited (returned), and so it has already tried to copy the temporary file to the permanent location.
However, since the temporary files doesn't yet have any changes, crontab decides there's nothing to do.
Editing the file in VSCode and saving it has no effect, other than to leave a dangling /tmp/... file hanging around (since crontab isn't there to clean up).
So what's the solution? We need a way to launch a Windows GUI application and prevent it from returning control to crontab until you are done editing.
I originally thought something from this question might work, but the problem is that the actual command that launches the Windows process is embedded in a shell script, which you can see with less "$(which code)" (or code "$(which code)"), but it's probably not a great idea to edit this.
So the next-best thing I came up with is a simple "wrapper" script around the (already-a-wrapper) code command. Create ~/.local/bin/code_no_fork.sh (could be anywhere) with:
#!/usr/bin/env bash
code $* > /dev/null
echo Press Spacebar to continue
read -r -s -d ' '
Credit: This answer for the Spacebar approach
Then:
EDITOR=~/.local/bin/code_no_fork crontab -e
After you make your edits in VSCode, simply press Space to allow the script to continue/exit, at which point crontab will (assuming no errors were detected) install the new Crontab.
Alternatives
This is should typically only be a problem with Windows GUI applications, so the other possible avenue is to simply use any Linux editor that doesn't fork. If you want a GUI editor, that's entirely possible as long as you are running a WSL release that includes WSLg support (now available for Windows 10 and 11).
I won't offer any individual editor suggestions since that would get into "opinion" and "software recommendation" territory, which is off-topic here.
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 new to the fish shell, and just trying to set my $EDITOR variable so that's it's persistent across sessions and reboots. Here's what I've tried so far:
Running set -gx EDITOR vim from the command line.
Running set -Ux EDITOR vim from the command line.
Running those commands, prefixed by set -e EDITOR to unset any previous value.
Adding the above commands to my ~/.config/fish/config.fish file (it complains set: Warning: universal scope selected, but a global variable “EDITOR” exists.)
Uninstalling oh-my-fish and removing all fish configs to start from scratch.
No matter what I do, the EDITOR variable always ends up being /usr/bin/nano whenever I open a new terminal, start a new session, or reboot. What's even more strange is that in ~/.config/fish/fishd.my-hostname, I see SET_EXPORT EDITOR vim, and nothing about nano. Is this some kind of fish default? If so, how can I set this correctly?
Edit: I'm running Fish 2.6.0 on Antergos Linux.
First, the fish config file is ~/.config/fish/config.fish. Editing the file you named won't have any effect. Second, fish does not have any default for, nor does it set, the EDITOR or VISUAL variables. So whatever is setting it to /usr/bin/nano is a customization unique to your system.
If you set -Ux EDITOR vim and do not set it in config.fish it should be set to vim even if it is already set when fish starts. Run that set command then do set -U | grep EDITOR and env | grep EDITOR to see that it is set as a universal variable and exported. Now type fish to start a sub-shell. Run the previous two commands and you should see that it is still set to the same value. Now type set -U EDITOR nano in the sub-shell followed by exit. In the earlier shell you should now see that EDITOR is set to nano.
Personally I don't like to use uvars for this since at the moment they are per-machine. I just do set -gX EDITOR (type -p vim) in my ~/.config/fish/config.fish. This ensures that if I start fish on a new machine on which I've installed my ~/.config/fish directory I get my expected defaults.
The other reason not to use a uvar in this way is that the resolution order is local scope, global scope, universal scope. Since environment vars imported when fish starts running are placed in the global scope they will shadow the uvar you defined. Do not export universal variables. It is unlikely to produce the desired results. Simply set -gx the var in your config.fish script.
P.S., When asking questions of this nature you should always include pertinent facts such as the OS you're using and the fish version.
My pyenv is working just fine, but it does not seem to be running my activate script located at /usr/local/var/pyenv/versions/project/bin/activate.fish
When activating my environment it gives the following output, but it does not echo anything from the activate script, which indicates that it is not running.
dani#localhost ~/d/project> pyenv activate project
pyenv-virtualenv: prompt changing not working for fish.
Of course I can just source the file manually, but I'm too eager to find out why it is not running. Is there some kind of debug mode? I'm not sure how to approach.
Actually,
Virtual environment is activated but the message just says that your prompt wasn't changed. Updating prompt was intentionally removed from fish shell.
you can find detailed information here;
https://github.com/pyenv/pyenv-virtualenv/issues/153
If you want to see virtual environment is really activated or not,
run the following command;
pyenv which python
it should print something like;
.pyenv/versions/{your-virtual-env}/bin/python
try this:
set PYENV_ROOT $HOME/.pyenv
set -x PATH $PYENV_ROOT/shims $PYENV_ROOT/bin $PATH
pyenv rehash
I'm trying to add a new ssh key. I've started the service using "ssh-agent -s", and I get this response:
SSH_AUTH_SOCK=/tmp/ssh-tUlzwbxYNLaZ/agent.9516; export SSH_AUTH_SOCK;
SSH_AGENT_PID=8992; export SSH_AGENT_PID;
echo Agent pid 8992;
But when I do "ssh-add ~/.ssh/id_rsa" I get the error "Could not open a connection to your authentication agent." Is the start command not working? I'm not sure what the output of the start command means.
The output that you show above needs to be evaluated. Very often this is done automatically by starting ssh-agent like eval `ssh-agent`. This causes
SSH_AUTH_SOCK=/tmp/ssh-tUlzwbxYNLaZ/agent.9516; export SSH_AUTH_SOCK;: the SSH_AUTH_SOCK environment variable to be set to the given value.
SSH_AGENT_PID=8992; export SSH_AGENT_PID;: the SSH_AGENT_PID environment variable to be set to the given value.
These two variables need to be set for ssh-add to be able to find the agent. If you want to evaluate them manually you can just copy those commands, paste them into your terminal or console, and hit Enter. Then try using ssh-add again.
The last line, echo Agent pid 8992;, simply prints out the ssh-agent process ID for your information.
These variables cannot be hard-coded because the socket and PID aren't predictable. Each time you start ssh-agent you need to use whatever values it prints out.
Note that these variables only get set for the current shell. So if you do it in a terminal window and then work in that window you should be fine, but if you close the window and open a new terminal it won't work anymore. Similarly if you are logged into a console, then log out and back in again.
Most modern desktop environments start ssh-agent and set the appropriate environment variables for you, so if you're using Gnome or KDE or Unity or something you shouldn't have to do this. If you are manually starting your environment or using something more bare-bones that doesn't handle this for you you should probably add eval `ssh-agent` to your X startup file, e.g. .xinitrc so that it runs before starting X.