I would like to know if it is possible to run certain a set of initial commands when the VScode terminal startups. Could these commands be defined in the workspace settings of the project?
This is useful when changing between projects using different versions of Node.
Related
I was wondering whether there is a way to execute a Node.js program using some keyboard shortcut in Visual Studio Code.
For instance, while I am coding in the editor, instead of having to manually open the Integrated Terminal in Visual Studio Code and then type let's say node app.js, can I just configure a key to automatically do this?
Below shown is an illustration of what I want:
I want to run the file app.js in the terminal without having to go there again and again and type node app (or even by using the up arrow key to bring the last entry from the terminal's history).
Note: I found one way of doing so and that is to go to the Debug console. But sometimes, it doesn't display full results. For instance, when logging a module, it displays one line with a caret which can be used to inspect details of the logged object further, but when I press the caret, it says that there is no debugger to view the object.
You can create a shell task or an npm task that runs node app.js. You can then bind a hotkey for running a task in the VS Code key binding settings.
The npm extension should automatically detect every script in the package.json file and provide them as a task if the task.autoDetect setting is set to on. You can simply add a start script that runs node app.js. I have then set up a hotkey that reruns the latest task:
{ "key": "ctrl+r b", "command": "workbench.action.tasks.reRunTask" },
I have setup on my PC a miniconda python environment where I have installed the databricks-connect package and configured the tool with databricks-connect configure to connect to a databricks instance I want to use when developing code in the US.
I have a need to connect to a different a different databricks instance for developing code in the EU and I thought I could do this by setting up a different miniconda environment and installing databricks-connect in that environment and setting the configuration in that environment to point to the new databricks instance.
Alas, this did not work. When I look at databricks-connect configure in either miniconda environment, I see the same configuration in both which is the configuration I last configured.
My question therefore is: Is there a way to have multiple databricks-connect connections at the same time and toggle between the two without having to reconfigure each time?
Thank you for your time.
Right now, databricks-connect relies on the central configuration file, and this causes problems. There are two approaches to workaround that:
Use environment variables as described in the documentation, but they should be set somehow, plus you need to have different python environments for different versions of databricks-connect
Specify parameters as spark configuration (see in the same documentation)
For each DB cluster, do following:
separate python environment with name <name> & activate it
install databricks-connect into it
configure databricks-connect
move ~/.databricks-connect into ~/.databricks-connect-<name>
write wrapper script, that will activate python environment & symlink ~/.databricks-connect-<name> into ~/.databricks-connect (I have such script for Zsh, it could be too long to paste it here.)
I want to be able to use linux environment variables in vscode workspace settings (specifically $HOME) so that I can specify paths that aren't specific to a user. In this case I am trying to set the java.home setting.
I have tried using ${env:HOME} but this doesn't seem to work. I suspect this is only for vscode tasks.
{
"java.home": "${env:HOME}/.sdkman/candidates/java/8.0.222.hs-adpt/"
}
Get the following error message at the moment:
The java.home variable defined in VS Code settings points to a missing or inaccessible folder (${env:HOME}/.sdkman/candidates/java/8.0.222.hs-adpt/)
Environment variables in Linux are supported now in VSCode (although I don't know since when or which version exactly). I have VSCode for Linux 1.73.1.
You can now use the following (just like in the question above):
{
"java.home": "${env:HOME}/.sdkman/candidates/java/8.0.222.hs-adpt/"
}
I'm trying to configure a NoMachine remote desktop to run xmonad. One thing I keep running into is that the default xmonad installation instructions require logging out and logging back in. In a remote desktop app like NoMachine, there's no way to log out as a user -- only disconnect from the session.
I have the option to create a new Gnome, KDM, or XDM desktop, or a custom session which can do things like run a default X client script, or a custom command at startup.
Does anyone have experience with how best to configure this?
If you want to just run a plain xmonad session (and not, for example, use xmonad as the window manager of, say, GNOME), then it should suffie to use the option of running a custom command at startup, and simply make that command xmonad.
I just wanted to know if there is any way to simply read environment variables I'vet set using SET in cmd.
I've read about process.env.[ENVVAR], but when I console.log the variable I've set in cmd, it shows undefined.
On other threads I read that it isn't even possible at all to access windows env. variables.
So what is actually right?
I will summarize my comments into an answer.
When you start node.js from a cmd window, a copy of the current user environment is created just for that node.js process. That environment can be accessed via process.env.
That environment will not be changed by any outside agents. Once the node.js process is started, its environment belongs uniquely to the node.js process.
Making changes to the Windows default environment via Windows Control Panel > System > Advanced System Settings > Advanced > Environment Variables affects what variables/values will be set in newly created environments (e.g newly created cmd windows). It does not affect currently open or running environments.
Using process.env, you can read all the existing environment variables in your own environment. You can modify the process.env object directly (changing values, removing properties, etc...) and those changes will be seen by any other code within your process accessing process.env. But outside changes to an environment in some other cmd window will not affect the environment in a running node.js program.