I am beginner and I'm trying to connect my GitHub profile with my local machine.
I'm following the steps but my git cmd does not recognise eval.
I have generated a key and am trying to add an SSH key to the ssh-agent.
This is the message I get:
'eval' is not recognized as an internal or external command,
operable program or batch file.
The command I run is:
eval "$(ssh-agent -s)"
You are running the command in the wrong console.
Open Powershell, Git Bash console or WSL bash - depending on how you installed Git - because this is just Command Prompt (cmd.exe) which doesn't support even the syntax you're trying (Bash).
Or alternatively, ensure ssh-agent's folder is in the PATH environment variable. Then you'll be able to call it even from a different console, that is, a part of the eval $(ssh-agent -s) command.
What that part does is nevertheless incompatible with the Command Prompt console:
-s Generate Bourne shell commands on stdout. This is the default if
SHELL does not look like it's a csh style of shell.
and outputs something like this:
SSH_AUTH_SOCK=/tmp/ssh-jR0WcW41z0yX/agent.1918430; export SSH_AUTH_SOCK;
SSH_AGENT_PID=1918431; export SSH_AGENT_PID;
echo Agent pid 1918431;
which might be worked around by using Command Prompt's SET command like this:
set SSH_AUTH_SOCK=c:\some\path\agent.1918430
set SSH_AGENT_PID=<the number you got>
and then run the commands following that eval $(ssh-agent -s) instruction.
Related
I'm trying to open a WSL (Ubuntu) tab in Windows Terminal, and then run a command in that tab using WSL. I use the following PowerShell command for that:
wt new-tab -p "WSL (Ubuntu)" wsl echo "hallo"
The problem is, after echo has run, the tab closes immediately.
Is there a way to keep it open?
When you pass a command line to wt.exe, the Windows Terminal CLI, it is run instead of a shell, irrespective of whether you also specify a specific shell profile with -p.
Thus, to achieve what you want:
Your command line must explicitly invoke the shell of interest...
...and that shell must support starting an interactive, stay-open session in combination with startup commands.
While PowerShell supports this, POSIX-compatible shells such as bash - WSL's default shell - do not.
A - suboptimal - workaround is the following:
wt -p 'WSL (Ubuntu)' wsl -e bash -c 'echo ''hello''\; exec $BASH'
Note:
Inexplicably, as of Windows Terminal v1.13.11431.0,
the ; char. inside the quoted -c argument requires escaping as \; - otherwise it is interpreted by wt.exe as its separator for opening multiple tabs / windows.
The above executes the specified echo command first, and then uses exec to replace the non-interactive, auto-closing original shell with an interactive, stay-open session via exec. The limitation of this approach is that any state changes other than environment-variable definitions made by the startup command(s) are lost when the original shell is replaced.
A better, but more elaborate solution is possible: create a temporary copy of Bash's initialization file, ~/.bashrc, append your startup commands, and pass the temporary copy's file path to bash's --rcfile option; delete the temporary copy afterwards.
I am writing a perl script, and I want to run a simple shell command to use a certain version of NVM:
Here is my code snippet:
print "\n*** Switching to correct nvm environment for dashboard builds\n";
system("nvm use 8.12.0") == 0 or die $?;
But I am getting the following error:
Can't exec "nvm": No such file or directory
Can someone help?
Update (June 30, 2021):
I also tried adding the command:
my $nvm_version = "8.12.0";
system ("bash", "-lic", "nvm use $nvm_version");
But nothing happens:
I'm not familiar with nwm, but I think I get the gist of what it does. And if so, the attempt is fundamentally flawed. Even if you fixed this to run the proper shell so that nvm could run, I believe all the tool does is change the shell's environment variables, a shell you immediately exit. This means it would have no effect even if if it ran successfully.
Again, it this tool does what I think it does, such tool are meant to be used in interactive shells. In other instances, you simply use the path the to correct executable instead of relying on the PATH.
With that in mind, you can use the following to run the command in bash:
# Non-interactive shell.
system("bash", "-c", "nvm use 8.12.0")
or
# Interactive shell.
# This is improper and fragile as interactive shells
# often create aliases that override basic commands.
system("bash", "-ic", "nvm use 8.12.0")
Just to reiterate, at least one of these will allow the command to run (if it normally works from bash), but I believe it's unlikely this will produce the results you expect.
The nvm command is shell function which is different from a shell command. Also the nvm command is not an exported function so it will not be seen by sub shells. For example, in Bash shell:
$ nvm ls
-> v15.0.1
$ my-test-script.sh
./my-test-script.sh: line 3: nvm: command not found
where my-test-script.sh is:
#! /bin/bash
nvm use 16.4
The error nvm: command not found is because nvm is not exported. I can source the script in the current shell context to make it work:
$ source my-test-script.sh
Now using node v16.4.0 (npm v7.18.1)
$ node --version
v16.4.0
So a Perl script cannot change the node version of the current shell, but it can calculate the version and pass it back to shell, which can set the version. For example:
$ nvm use $(perl -E'$v=15.0; print $v')
Now using node v15.0.1 (npm v7.0.3)
I've created aliases in c:\Users\user\.bash_profile and in C:\Program Files\Git\etc\profile.d\aliases.sh but both configs getting ignored by VSCode integrated terminal, which is configured to use git bash:
"terminal.integrated.shell.windows": "C:\\Program Files\\Git\\bin\\bash.exe",
if I open GitBash itself - aliases works fine
how do I force integrated terminal to respect the configs?
You can try adding to the settings:
// The command line arguments to use when on the Windows terminal.
"terminal.integrated.shellArgs.windows": [
"--login", "-i"
],
-i - force the shell to run interactively.
--login - make this shell act as if it had been directly invoked by login. When Bash is invoked as an interactive login shell, or as a non-interactive shell with the --login option, it first reads and executes commands from the file /etc/profile, if that file exists. After reading that file, it looks for ~/.bash_profile, ~/.bash_login, and ~/.profile, in that order, and reads and executes commands from the first one that exists and is readable.
When invoked as an interactive shell with the name sh, Bash looks for the variable ENV, expands its value if it is defined, and uses the expanded value as the name of a file to read and execute. Since a shell invoked as sh does not attempt to read and execute commands from any other startup files, the --rcfile option has no effect. A non-interactive shell invoked with the name sh does not attempt to read any other startup files.
Read more.
As an alternative you can use the .bashrc file instead of .bash_profile.
The solution using the "--login" and "-i" shell arguments did not work for me. What did work was using the bash "-rcfile" shell argument, like this, in my settings file:
"terminal.integrated.shellArgs.windows": [
"-rcfile",
"c:\Users\\.bash_profile", ],
... where <userid> is my Windows userid and the alias commands are in a file called ".bash_profile" that is located in c:\Users\<userid>
I simply switched to my root user directory c:\Users\user then ran source .bashrc. This did the trick on my machine, hope it helps.
Create .bashrc in c:\Users\username
Add an alias, e.g alias gotossh="cd /c/users/username/.ssh"
In your terminal, run source .bashrc while in c:\Users\username
Confirm that the alias works by running alias
You might not have a .bashrc file in the users folder which is important to note.
Also remember to write the paths correct and don't leave any space between the equals in e.g alias="somecommand"
As of 2020 there is no need to add the shellArgs.
My problem is connecting throguh Net::SSH::Perl vs Connecting through SSH.
my shell variables ( command: export ) aren't the same.
This fact prevents me from executing user's script that depends on the shell env vars.
For example:
if i execute through perl ( Net::SSH::Perl ) the command: "export" I get:
MAIL=/var/mail/username
PATH=/usr/local/bin:/bin:/usr/bin
PWD=/username
SHELL=/bin/ksh
SSH_CLIENT='myIPAddress 1022 22'
SSH_CONNECTION='myIPAddress 1022 remoteIPAddress 22'
USER=myusername
while executing the same command through regular ssh connecting I get 42 rows of ENV VARS.
Other example:
if i execute through perl ( Net::SSH::Perl ) the command: "tty" I get:
not a tty
while executing the same command through regular ssh connecting I get:
/dev/pts/3
What am I missing here ?
For the environment variables, it sounds like ~/.bashrc isn't getting sourced. You should be able to source it yourself:
$ssh->cmd(". ~/.bashrc");
For the terminal, allocating a pty is not necessary for many tasks, so it is not normally done for non-interactive shells; however, you can pass the use_pty option when creating your ssh object to tell it to create a pty.
from the Net::SSH::Perl documentation:
use_pty
Set this to 1 if you want to request a pseudo tty on the remote machine. This is really only useful if you're setting up a shell connection (see the shell method, below); and in that case, unless you've explicitly declined a pty (by setting use_pty to 0), this will be set automatically to 1. In other words, you probably won't need to use this, often.
The default is 1 if you're starting up a shell, and 0 otherwise.
Chas, that would not work either as Net::SSH::Perl (and for that matter, most other Perl SSH clients) runs every command in a new shell session, and so side effects do not persist between commands.
The solution is to combine both commands as follows:
$ssh->cmd(". ~/.bashrc && $cmd");
I have script lets say:
C:\foo.bsh
I want to be able to run this command via the windows run command:
Start -> Run
Windows Key + R
and type something small like 'foo' and hitting return.
However, I do not want a cmd prompt to be visible. This script does some preprocessing for an IDE. I do not want the cmd prompt to be open for the lifetime of the IDE process.
I have tried:
1) Creating a bat file with the following contents:
c:\cygwin\bin\bash --login "C:\foo.bsh" (this fails because it keeps a cmd open)
2) Converting the above bat file to an exe using bat_2_exe_converter (does not make the cmd silent)
thoughts?
EDIT: The solution so far suggests something to type from an actual cygwin shell. I am trying to get a faster solution by having something short I can type in the Windows run command. Also, the nohup command; exit doesn't automatically kill the box - however I can manually kill it without killing the IDE process. The run command accepts shortcuts (.lnk's), bat's, exe's.
Try the run.exe command of cygwin. It is a big install, a complete unix environment for your Windows machine. Suppose you installed it at c:\cygwin\.
No mystery, just run c:\cygwin\bin\run.exe <your command here> and you will have your no dos window execution.
You can run it from any DOS window (run cmd.exe from the start menu). You don't need to run it from cygwin.
To make it easier, append C:\cygwin\bin to your %PATH% env var (My Computer → Properties → Advanced → Environment Variables) (Kudos to Felipe Alvarez comment).
Now you can just type
c:\cygwin\bin\run.exe "C:\foo.bsh"
You must create a link in your Start Menu with this command so will be able to run it with Win-R.
Here is the man page of the runcommand:
$ man run
RUN(1) run 1.3.0 RUN(1)
NAME
run - start programs with hidden console window
SYNOPSIS
run [ -p path ] command [ -wait ] arguments
runcommand [ -p path ] [ -wait ] arguments
DESCRIPTION
Windows programs are either GUI programs or console programs. When
started console programs will either attach to an existing console
or create a new one. GUI programs can never attach to an exiting con‐
sole. There is no way to attach to an existing console but hide it if
started as GUI program.
run will do this for you. It works as intermediate and starts a pro‐
gram but makes the console window hidden.
With -p path you can add path to the PATH environment variable.
Issuing -wait as first program argument will make run wait for program
completition, otherwise it returns immediately.
The second variant is for creating wrappers. If the executable is
named runcommand (eg runemacs), run will try to start the program (eg
emacs).
EXAMPLES
run -p /usr/X11R6/bin xterm
run emacs -wait
runemacs -wait
run make -wait
AUTHORS
Charles S. Wilson
Harold L Hunt II
Jehan Bing
Alexander Gottwald
Version 1.3.0 November 2005 RUN(1)
You can use either...
c:\cygwin\bin\bash -l /path/to/script_to_interpret.sh
...or...
c:\cygwin\bin\bash -l -c /path/to/executable_script.sh
Note: the -l flag tell bash to "act as if it had been directly invoked by login" and use Bash Startup Files. This is important in that it sets your $PATH and other things you rely on when you launch a cygwin terminal. If you don't include -l or --login you will get "command not found" when you try to call anything except of a bash builtin.
The difference between the 2 is like the difference between doing...
bash script_to_interpret.sh
...and...
./executable_script.sh
...in *nix. The former interprets the script using bash. The latter executes the script (only if it has chmod +x executable_script.sh) and interprets it according to its "shebang" line. The latter method is also what you want to do if your executable is not a script at all, like a *nix binary compiled from source.)
It has been bugging me for a while I couldn't find the solution for this, but I finally got the right mix together.
You can simply do the following if you have cygwin on your PATH:
run bash test.js
If cygwin is not on your path, you can do this:
c:\cygwin\bin\run.exe -p /bin bash test.js
If you are looking for more control over the created window (maximize, etc) it looks like you can use cygstart also.
Sources:
- neves answer above (though that wasn't enough by itself for me personally to figure it out)
- http://cygwin.com/ml/cygwin/2008-09/msg00156.html
As the terminal can't close while your script is still running, try the command:
"nohup C:\foo.bsh; exit"
This way your script will be backgrounded and detached from the terminal, and it should exit quickly so the terminal goes away. I think that the window may still 'flash' with this approach, but the results should be better than what you're getting.
I'm running Cygwin64 and the xwin server link points to:
C:\cygwin64\bin\run.exe /usr/bin/bash.exe -l -c /usr/bin/startxwin.exe
This creates an icon AND a notification on the taskbar. I don't like that. The icon is rather useless, the notification has all your menu options from .XWinrc.
So... I wrote a .vbs script to silently run this command and make the icon go away:
Set objShell = CreateObject("WScript.Shell")
objShell.Run("C:\cygwin64\bin\run.exe /usr/bin/bash.exe -l -c /usr/bin/startxwin.exe"), 0
Another imperfect possibility is to run the script via a shortcut and set the shortcut's Run option to "minimized".
Go to the directory where you have installed cygwin(on my machine it is c:/cygwin64/bin)
Once there simply type "bash.exe"