I recently updated my intellij to 2022.1, and I observe that echo command is not working as expected.
On windows cmd:
echo %JAVA_HOME%
....\java\zulu11.56.19-ca-jdk11.0.15-win_x64
In intellij terminal:
echo %JAVA_HOME%
%JAVA_HOME%
It used to work fine in previous version of intellij.
Am I missing some configuration?
Related
I am using oh-my-zsh for my terminal. I have set IntelliJ to use /bin/zsh as the shell path. However no environment variable in my .zshrc file ever seems to get picked up. I'm defining environment variables like this (for instance):
export GOOGLE_APPLICATION_CREDENTIALS="$HOME/mailcreds.json"
But if I run:
echo $GOOGLE_APPLICATION_CREDENTIALS
Nothing comes up.
Set environment variables in ~/.profile instead of ~/.bashrc or ~/.zshrc, see this issue for details.
For me, the issue was that I load tmux automatically using .zshrc.
I followed the solution here: https://youtrack.jetbrains.com/articles/IDEA-A-19/Shell-Environment-Loading
Wrapped just the export ZSH_TMUX_AUTOSTART=true like this:
if [ -z "$INTELLIJ_ENVIRONMENT_READER" ]; then
export ZSH_TMUX_AUTOSTART=true
fi
For Ubuntu, I edited my IDE desktop launcher to run zsh with login interactive:
Go to /usr/share/applications (where the desktop entry usually located).
Edit jetbrains-idea.desktop(might be named differently).
Change Exec field to include /bin/zsh -l -i -c "/opt/intellij/bin/idea.sh".
The final result of the file:
[Desktop Entry]
Version=1.0
Type=Application
Name=IntelliJ IDEA Ultimate Edition
Icon=/opt/intellij/bin/idea.svg
Exec=/bin/zsh -l -i -c "/opt/intellij/bin/idea.sh" %f
Comment=Capable and Ergonomic IDE for JVM
Categories=Development;IDE;
Terminal=false
StartupWMClass=jetbrains-idea
StartupNotify=true
Shared the same wrong behavior with Intellij in Manjaro (Arch), which uses zsh by default.
The issue comes with Flatpak, switching to Snap or downloading binaries directly from vendor's page got this solved.
Is similar to this issue (PyCharm): https://github.com/flathub/com.jetbrains.IntelliJ-IDEA-Ultimate/issues/23.
After installing Intellij Idea using flatpak on Clear Linux I'm not able to make it run svn executable.
I added ---filesystem=host to flatpak permissions and tried to set executable path to /run/host/usr/bin/svn but with no luck (path is available/exists, though Intellij keeps complain)
svn command is normally available from system terminal.
When I try to run /run/host/usr/bin/svn command via Intellij Idea built-in terminal, I've got error that library is not available:
sh-5.0$ /run/host/usr/bin/svn
/run/host/usr/bin/svn: error while loading shared libraries: libsvn_client-1.so.0: cannot open shared object file: No such file or directory
I also tried set flatpak-spawn. Following command works perfectly fine in Intellij Idea built-in terminal:
/usr/bin/flatpak-spawn --host /usr/bin/svn, though when set as path to svn executable still gives me Intellij Idea error:
"The path to Subversion executable is probably wrong"
Could anybody please help with making it work?
TLDR: You probably need to add the path to svn into your IntelliJ terminal Path.
Details:
It looks like you are having a path issue. I had a similar problem running kubectl running PyCharm installed from a flatpak on Pop_Os.
If I try to run kubectl I see the following:
I have kubectl installed in /usr/local/bin. This is a screenshot from my 'normal' terminal.
In the PyCharm terminal this location is mounting under /run/host/usr/local/bin/.
If I look at my path in the PyCharm terminal, it is not there.
So I'll add the /run/host/usr/local/bin/ to my path and I can then run kubectl:
To make sure this comes up all the time, I need to add the PATH to the Terminal settings:
I can now execute any of the commands in my /usr/local/bin dir.
I found a really ugly solution for dealing with SVN with the JetBrains family, which does actually answer the question. But in a very roundabout way. Unfortunately Alex Nelson's solution didn't work for me.
You would think the Flatpak would come with a valid SVN, since it's actually part of the expected requirements for the program...
When in the terminal, you can run
cd ..
/usr/bin/flatpak-spawn --host vim ./svn
Then press i to go into input mode, then paste the following in the opened text file (Basically what it does is create an executable which passes it to the flatpak-spawn invocation):
#!/bin/bash
/usr/bin/flatpak-spawn --host /usr/bin/svn $#
Save and quit from vim (ESC, then :wq!). Make it executable:
chmod +x svn
Then in IntelliJ's menu, set the "path to svn" to
/home/<yourusername>/IdeaProjects/svn
It's worked for everything I've tried... Hope this helps out anyone else who was struggling with this.
I am using a similar solution to caluga.
#!/bin/sh
cd
exec /usr/bin/env -- flatpak-spawn --host /usr/bin/env -- svn "$#"
exec makes it replace the wrapper script process so the wrapper script process can end.
I'm using /bin/sh instead of /bin/bash as bash features are not needed.
using /usr/bin/env, but maybe not necessary if PATH is set up right.
remember to quote "$#" in case there are spaces in arguments.
I am putting it in ~/.local/bin and referencing it with its absolute path in the IntelliJ settings (Settings -> Version Control -> Subversion -> Path to Subversion executable).
I also was running into problems with IntelliJ saying that /app/idea-IC path does not exist. Figured that something outside the flatpak (i.e. svn or env) was trying to change directory to the working directory from where the wrapper script was invoked (inside the flatpak). Using cd allows the wrapper script to change to a directory that exists both inside the flatpak and on the host.
Fedora Silverblue or toolbox users might want to use dev tools inside their toolbox, in which case you can do:
#!/bin/sh
cd
exec /usr/bin/env -- flatpak-spawn --host toolbox run svn "$#"
I've asked this question in the swagger github repository but the community doesn't look very responsive, so I'm going to try here.
Following the README I'm running this commands to generate a PHP client (but it could be any other language):
git clone https://github.com/swagger-api/swagger-codegen
cd swagger-codegen
mvn clean package
java -jar modules/swagger-codegen-cli/target/swagger-codegen-cli.jar generate
\
-i http://petstore.swagger.io/v2/swagger.json \
-l php \
-o /var/tmp/php_api_client
and I get the following error:
Error: Unable to access jarfile modules/swagger-codegen-cli/target/swagger-codegen-cli.jar
Does anybody have the same error? I'm trying to figure out if it's just me. Maybe I'm missing something.
As of today (1/10/19) it only works with Java version 7 or 8. I had to downgrade from version 10 to make it work.
I'm in the process of moving all my projects to individual modules in IntelliJ rather than having one module in the entire git repo, and my IntelliJ builds stopped working. I notice it uses lime builds even though my module is set to openfl (and always has as far as I know)
openfl test flash -debug
this works
lime build GassyRickAstley.xml flash -debug -verbose
this does not. Full gist of both -v
Lime Command-Line Tools (2.9.1)
Initializing project...
Using project file: GassyRickAstley.xml
Warning: Could not read HXCPP config: /Users/booboo/.hxcpp_config.xml
Using target platform: FLASH
Running command: UPDATE
- Embedding asset: removed for brevity
- Copying template file: removed for brevity
Running command: BUILD
- Running command: haxe -main ApplicationMain -cp /usr/local/lib/haxe/lib/flixel/git -D flixel=4.3.0 -cp /usr/local/lib/haxe/lib/openfl/3,6,1 -D openfl=3.6.1 -cp /usr/local/lib/haxe/lib/lime/2,9,1 -D lime=2.9.1 -cp /usr/local/lib/haxe/lib/actuate/1,8,7 -D actuate=1.8.7 -cp /usr/local/lib/haxe/lib/ash/1,5,4/src -D ash=1.5.4 -cp source -cp lib -cp /usr/local/lib/haxe/lib/openfl/3,6,1/extern -cp ../Krakel/source -cp ../../lib/HxAssert/src -D native-trace -D HXCPP_QUIET -D openfl-next -D tools=2.9.1 -D flash-use-stage -D no-compilation -D openfl-flash -D verbose=1 -D web --macro flixel.system.macros.FlxDefines.run() -swf-lib export/flash/obj/assets.swf -swf-version 11.8 -swf export/flash/bin/GassyRickAstley.swf -cp export/flash/haxe -debug
georges-mbp:Gassy Rick Astley booboo$
It doesn't seem like anything went wrong, but I'm pretty shit with analyzing terminal output.
For now I can just build manually, but not having breakpoints is gonna get pretty lame, pretty fast. Any help is appreciated.
Bonus question. When I run/test the project in open fl and close the game's window the active terminal process never ends. I have to close the terminal, reopen and cd my directory again. is there a way around this?
It looks like it may have worked. openfl test flash is similar to running openfl build flash && openfl run flash, which in turn should behave practically the same as lime build flash && lime run flash.
I think your lime build flash command is working properly, but is exiting because the application has finished building. If you use lime test flash instead, it might build-and-run for you, as the other command does?
I'm trying to get gnome-terminal to work in codelite under
setting > preferences > terminal
I tried
gnome-terminal -x '$(CMD)'
but it gives me the following error
Failed to execute child process "/bin/sh -f /usr/lib/codelite/codelite_exec ./program" (No such file or directory)
I'm running Linux Mint 18.
Solution is to run
sudo update-alternatives --config x-terminal-emulator
from a terminal and select
/usr/bin/gnome-terminal.wrapper
as default terminal.
CodeLite uses x-terminal-emulator. So as long as you define x-terminal-emulator to point to the correct terminal it will work.
See this post for more information
I just came across this problem after upgrading to CodeLite 10.0 from the CodeLite repository. The problem occurs because CodeLite is now installing things in different directories - namely codelite_xterm and codelite_exec, which are now installed to /usr/bin/.
For me, on Ubuntu 16.10, I found the easiest solution was to change Settings > Preferences > Terminal to:
/usr/bin/codelite_xterm '$(TITLE)' '$(CMD)'
You can then run:
sudo update-alternatives --config x-terminal-emulator
to select the terminal you wish to use (the default on Ubuntu 16.10 is gnome-terminal, so you won't have to run the last command if you're happy with gnome-terminal).