I wrote a build script for my project (maven, grunt as well as some server-reconfiguration), and when I use the WebStorm command-line with
~/Projects/javaee-angularjs$ ./launchServer.sh
Everything works as expected.
However, when I configure the file to be run by WebStorm (the green triangle top-right) it fails because of: /home/user/Projects/javaee-angularjs/launchServer.sh: line 29: grunt: command not found
The run-config should be absolutely correct:
working directory is the correct one and the script is found to begin with.
Any Idea what could cause this weird behavior?
P.S. I don't know whether WebStorm can run bash natively, since I've always had the bash plugin installed.
Try starting WebStorm from terminal - does the issue persist?
When being launched from desktop/System menu, WebStorm only sees environment variables configured in ~/.profile (login shell), but not in interactive shell configuration files (like ~/.bashhrc). Possible workarounds:
Workaround 1: make required variables available in a login shell (i.e. for bash, move them from .bashrc to .bash_profile).
Workaround 2: run IDE from a terminal, via bin/webstorm.sh
Workaround 3: edit the desktop launcher and set command to /bin/bash -l -i -c "/path/to/webstorm.sh"
see also https://youtrack.jetbrains.com/issue/IDEABKL-7589
The error sounds like Webstorm cannot find grun in its path. Try using the full path to the grunt command.
Related
I'm running Ubuntu-20.04 through WSL2 on my Windows 10 laptop. I've started having an issue in VSCode where the integrated terminal isn't getting its $PATH initialized correctly.
If I open an Ubuntu shell through Windows Terminal and run echo $PATH I get the following output:
/home/<user>/bin:/home/<user>/.nvm/versions/node/v15.1.0/bin:/usr/lib/jvm/java-1.11.0-openjdk-amd64/bin:/opt/devkitpro/tools/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/mnt/c/Program Files/Common Files/Oracle/Java/javapath:/mnt/c/Program Files (x86)/Common Files/Oracle/Java/javapath:/mnt/c/WINDOWS/system32:/mnt/c/WINDOWS:/mnt/c/WINDOWS/System32/Wbem:/mnt/c/WINDOWS/System32/WindowsPowerShell/v1.0/:/mnt/c/WINDOWS/System32/OpenSSH/:/mnt/c/Program Files (x86)/ATI Technologies/ATI.ACE/Core-Static:/mnt/c/Program Files (x86)/AMD/ATI.ACE/Core-Static:/mnt/c/Program Files (x86)/Calibre2/:/mnt/c/Program Files/Calibre2/:/mnt/c/Program Files/PuTTY/:/mnt/c/Program Files/FileBot/:/mnt/c/Users/<User>/AppData/Local/Microsoft/WindowsApps:/mnt/c/Users/<User>/AppData/Local/Programs/Microsoft VS Code/bin:/snap/bin
However once connected to WSL through VSCode if I run the same command in the integrated terminal I get:
/home/<user>/.local/bin
This means I can't even run the most basic commands like ls.
I can't understand why this is happening? Is there some setting in VSCode that would be interfering with my shell initialization, preventing $PATH from getting set correctly? I can't even run env to see what other environmental variables are doing.
The default shell in VSCode is set to bash.
It is my understanding that bash reads instructions from /etc/profile which sets shell variables. Could there be any reason these instruction are not being read?
Ok so I figured out what was causing the issue.
In my .bashrc, I had added the line:
export `PATH="/home/<user>/.local/bin"`
presumably to be able to access programs located there from any directory. For whatever reason this wasn't causing an issue when a shell was launched from Windows Terminal, but VS Code did not like it! Simply removing the aforementioned line from .bashrc solved the problem.
Guess I've got a lot to learn about .bashrc, .bash_profile, etc., and how these are accessed when starting up a bash shell. If anyone wants to shed light on this, feel free to comment below.
When running on Windows, I have changed my default terminal in the IntelliJ IDE from default Windows cmd to bash (I am using the one installed with Git, located at C:\Program Files\Git\bin\bash.exe). It works very well, the only trouble is that when running sbt from the terminal, some strange characters are shown (I assume they are some control characters intended to format the output).
This does not happen when I run sbt directly from the bash launched in the Windows as a standalone window.
Is there some setting (an environment variable or a config file) for any of the three components involved (sbt, IntelliJ, bash) I could change so that I do not see those formatting characters misinterpreted? If they would work and affect the formatting it would be a nice bonus, but that is less important to me.
IntelliJ:
Standalone:
sbt by default colors the console output, which does not work on Windows, but perhaps the launcher script doesn't disable the codes in the IntelliJ terminal script.
You can disable colors by passing the -Dsbt.log.noformat=true to sbt
You can preserve the colours and formatting if you add the following to your .bashrc file:
sbt() {
/c/progra~2/sbt/bin/sbt.bat "$#"
}
export -f sbt
.bashrc can be found (or created) in your %USERPROFILE% directory, e.g. C:\Users\{username}\.bashrc.
Substitute a different path to sbt.bat if necessary, but it needs to be without spaces.
Restart your terminal afterwards, or run source ~/.bashrc.
This exports a bash function that causes "sbt" to run the sbt batch file launcher instead of the shell script launcher that it would otherwise. The batch launcher clearly does a better job of processing the output on Windows. (I also use this for gcloud and gsutil commands that fall over in other ways when invoked from Bash.)
Find the sbtopts file (Windows location is C:\Program Files (x86)\sbt\conf by default) and make sure it contains following line and it is not commented out:
-no-colors
So I'm installing some things for coding and personal usage, and I need to run this in the terminal (I'm on Mac if you didn't read the title).
~/.bash_profile
It just says permission denied, Im running OSX 10.8.4 Mountain Lion. How do I bypass this?
On MacOS: add source ~/.bash_profile to the end of ~/.zshrc.
Then this profile will be in effect when you open zsh.
You would never want to run that, but you may want to source it.
. ~/.bash_profile
source ~/.bash_profile
both should work. But this is an odd request, because that file should be sourced automatically when you start bash, unless you're explicitly starting it non-interactively. From the man page:
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. The --noprofile option may be used when the shell is started to inhibit this behavior.
If you change .bash_profile, it only applies to new Terminal sessions.
To apply it to an existing session, run source ~/.bash_profile. You can run any Bash script this way - think of executing source as the same as typing commands in the Terminal window (from the specified script).
More info: How to reload .bash_profile from the command line?
Bonus: You can make environment variables available to OSX applications - not just the current Bash session but apps like Visual Studio Code or IntelliJ - using launchctl setenv GOPATH "${GOPATH:-}"
As #kojiro said, you don't want to "run" this file. Source it as he says. It should get "sourced" at startup. Sourcing just means running every line in the file, including the one you want to get run. If you want to make sure a folder is in a certain path environment variable (as it seems you want from one of your comments on another solution), execute
$ echo $PATH
At the command line. If you want to check that your ~/.bash_profile is being sourced, either at startup as it should be, or when you source it manually, enter the following line into your ~/.bash_profile file:
$ echo "Hello I'm running stuff in the ~/.bash_profile!"
No need to start, it would automatically executed while you startup your mac terminal / bash. Whenever you do a change, you may need to restart the terminal.
~ is the default path for .bash_profile
I was getting this error on zsh(mac os Big Sur 11.3), This is how i solved this :-
Go to Terminal.
cd /users/<yourusername>
Once you reach here issue a command :
ls -al
You will see a lot of files and one specific file .zprofile. This is your user profile. We need to edit this.
After this we need to edit the file. Issue the below command :
nano .zprofile
Once you issue this command file will be opened for edit. Add the path details for maven.
M2_PATH="/Users//code/apache-maven-3.8.1/bin" //add your path of maven diretory
PATH="${PATH}:${M2_PATH}"
export PATH
press ctrl + X and save the file.
Issue command after saving the file :
source .zprofile
Once done, you will be able to run the mvn command.
If the problem is that you are not seeing your changes to the file take effect, just open a new terminal window, and it will be "sourced". You will be able to use the proper PATH etc with each subsequent terminal window.
Im trying to automatically run a script using Cygwin via CMD. I basically created a BAT file that goes to the directory and executes an .SH file. SH files are accosiated with Cygwin, and I tried something like "cygwin update.sh" in the command line. But all it really does is open Cygwin. I want Cygwin to automatically run the script file. Is there any easy way to do this, I've been trying to find but can't. Thank you!
You'll want to call the shell script with a particular shell, e.g. bash.
When having Cygwin open, call which bash to figure out where the binary is located. Cygwin also comes with tools that can convert paths between Cygwin and Win32 form, which is pretty helpful in cases like yours.
There is one other thing that may work, depending on your setup. There is an environment variable named PATHEXT which declares file extensions that are deemed "executable" by CMD. This can be used to your advantage, if Windows is configured so that the shell's "open" verb executes the correct shell for the file extension .sh (in your case).
Good luck.
From Cygwin Terminal, read man mintty. Try something like the following from a Windows Command Prompt:
c:\cygwin\bin\mintty --hold always --exec /cygdrive/c/path/to/bash/script.sh
I also found this!
http://rothmanshore.com/2011/01/26/kick-off-a-cygwin-script-from-a-windows-bat-file-with-a-different-working-directory/
I didn't quite understand it at first, but then it worked as I wanted it. Just if anyone knows, is there a way to make the script run without the CMD window open?? Thanks
I've tried executing the following:
#!C:\cygwin\bin\bash.exe
ls ${WORKSPACE}
But that doesn't find ls (even if it's on the windows path). Is there any way to set this up?
UPDATE: In other words, I want to be able to set up a build step that uses cygwin bash instead of windows cmd like this page shows you how to do with Python.
So put your cygwin's bin directory in your PATH.
In case you don't know how to do it (Control Panel -> System -> Advanced -> Environment Variables), see: http://support.microsoft.com/kb/310519
That shell-script has two errors: the hash-bang line should be "#!/bin/bash", and ${WORKSPACE} is not a shell-variable. Hudson has a bunch of variables of its own which are expanded in the commands you specify to be run (i.e. when you add commands in the web gui).
If you want to run Hudson build step on the Cygwin command line, you need to figure out what command Hudson runs and in which directory.
To give a more specific answer, you need to show us how your project is configured and what steps you want to run separately.
Provided cygwin's bin folder is in your path, the following works for me:
#!/bin/sh
ls ${WORKSPACE}
I find Hudson does not pick up environment variable changes unless you restart the server.
you might want to try to give a full path to ls
/cygdrive/c/cygwin/bin/ls
One other thing that seems to work is to use this:
#!C:\cygwin\bin\bash.exe
export PATH=$PATH:/usr/bin
ls
But it would be nice not to have to modify the path for every script.
Have you thought about power shell? as much as I like cygwin, it's always been a little flaky, powershell is a solid fully functional shell on windows, another option is Windows Services for UNIX it gives you korn shell or c shell not quite as nice as bash but it gets the job done
You will need to pass the --login (aka -l) option to bash so that it will source Cygwin's /etc/profile and set up the PATH variable correctly. This will cause the current directory to get changed to the default "home" but you can set the environment variable CHERE_INVOKING to 1 before running bash -l and it will stay in the current directory if you need to preserve that.