E.g. I have a file:
my-cmd
#/usr/bin/env python
print('hello')
or:
my-cmd-2
#/usr/bin/env bash
echo hello
the syntax highlighting is not working. It does work when I have files with extension however such as my-cmd.py or my-cmd-2.sh, so it seems that it is unable to recognize those file types by shebang.
Is this just a bug on both the Python and Bash plugins? Or is there some more global setting for it? Or is it just not possible in Eclipse currently?
I looked under the "Association" settings but I could only see filename based methods there.
Tested on Eclipse CDT 2022-09 with extensions PyDev 10.0.1 and Bash Editor 2.8.0.
Related
I am on Ubuntu 20.04 and have both Python2 and Python3 installed natively. I have also installed Python through miniforge, a variant of miniconda. In VSCode I have both the MS Python extension and Pylance installed.
I use the miniforge python for my coding. This works perfectly fine in PyCharm.
However in VSCode, when I try to execute the same file I get errors. After investigating it seems that VSCode is picking native Python2 - even though I have the miniforge Python selected. In this picture it can be seen that the status bar at the bottom states Python interpreter selected is Python3. But the output window shows that the python interpreter is Python2.
A more confusing thing is when I use VSCode for Jupyter notebook files then it picks up the interpreter correctly and I have no issues.
I have checked both User and Workspace settings, and they all point to Python3. How can I fix this for standard .py files?
I prefer VSCode to PyCharm, but will need to use PyCharm till this is resolved.
It seems that your system console cannot see python3. You need to put the python3 in the PATH variable, before python2. Like:
PATH=path/to/python3:path/to/python2:$PATH
Also, make sure that the environment containing python3 is activated before command prompt appears. It can be done in bash_profile by adding a line like
conda activate my_env_with_python3
Try changing the settings "Python:Python path", "Python:default interpreter path" and "Python:conda path" also.
I have just bumped into something similar. The Run code option resulted in the file being run with the default interpreter instead of the venv-based one with necessary packages installed.
The fix was simply to use "Run python file" instead:
The run-code behavior must be customizable, something is mentioned e.g. here: Run Code vs Run Python File in Terminal for VSCODE but I didn't bother.
We have a project (C) (not a Cygwin exe project, but some embedded cross-compiled one), which has a Makefile designed to be used from within a Cygwin environment. That is the intended use is to open a Cygwin terminal, go t the project directory and run make from there.
I can import this project in Eclipse as a Makefile project, but apparently the regular build command from within Eclipse won't work as it is trying to invoke make in the native (Windows) environment. Is there a way to make Eclipse to run the Cygwin, invoke a make command in it and have the regular CDT error parsers to work? Perhaps by creating a custom builder?
I have managed to work around this problem by using a build script invoking some cygwin commands:
build.bat:
#echo off
c:\cygwin64\bin\bash --login -c "cd %cd:\=/%; make %*"
Breakdown:
c:\cygwin64\bin\bash --login -c "<command>" - used to invoke a command from within cygwin environment
cd %cd:\=/%; - is a "dos" %cd% variable (current path) with backslashes replaced by slashes - to avoid these to be stripped down as unescaped.
make %* - invoke the cygwin make command with all of the arguments passed to this batch file - this is to let Eclipse pass the build target and/or build flags.
Now in "project build" tab in eclipse I replace the make command with build.bat and it is working like a charm. The only drawback i to have this file in addition to the other project files, but since it is pretty generic it can be reused in any project with these restrictions.
I've been using the CoqIDE plugin for Vim on Linux machines for editing Coq files. Now I'm trying to install it on Windows 8. But when I try to source the plugin, I get
Your vim doesn't support Perl. Install it before using CoqIDE mode.
which is strange, because with :version I clearly see +perl/dyn included. Is this different from the +perl that I need?
I heard somewhere that you need to have Perl installed before Vim to get a Perl-enabled Vim, so I tried that as well. I uninstalled Vim, installed Strawberry Perl 5.18.2.2 (64bit), and reinstalled Vim. Still the same problem.
If the solution involves manually compiling binaries, I would really appreciate detailed instructions as I don't have any experience with it.
+perl/dyn just specifies that Vim has been compiled with dynamic Perl support; it doesn't yet check that the Perl library can be loaded successfully. To do that, try executing a Perl command, e.g.:
:perl VIM::Msg("Hello")
This probably yields on your system:
E370: Could not load library perl510.dll
Sorry, this command is disabled: the Perl library could not be loaded.
Next, you'd then have to investigate whether a proper Perl version has been installed and the DLL is accessible (though the PATH).
Download DWIMPerl for windows. I'm running win7 64 and gvim 7.4.2. Using strawberryperl and activeperl resulted in :echo has('perl') to yield 0. By switching to DWIMPerl (and ensuring my PATH env variables are proper) :echo has('perl') now yields 1 using the standard gvim distribution. This is important for vim extensions like dbext which require proper support for perl interfaces.
I'm trying to install Scalatra on windows seven and need to change a file to executable...the Scalatra documentation says to do this, which is unix. What is the windows equivalant?
chmod u+x srt
You can simply open the relevant folder with a unix command prompt (I use git bash) and execute the unix commands from there
To get scalatra-sbt going on Windows, either port you own sbt.bat from scalatra-sbt, or install chmod via cygwin.
Assuming you've successfully installed the rest of Conscript and giter8, you can start a project that downloads scalatra-sbt. From there, one can look through the ./sbt source, and port the bash script functionality to your own windows specific script, or install a unix compatibility layer into Windows. If you go down the "windows specific script" route, perhaps the scalatra-sbt would appreciate the project contribution.
The "unix compatibility layer" route will eventually allow you to run ./sbt. chmod is a unix command line function, and is provided in a default package of the tool set cygwin, which provides a complete lunix-like environment. Once inside a cygwin terminal, you can chmod your file, as mentioned in the scalatra-sbt first project.
Diving into the contents of ./sbt from scalatra-sbt, this is actually unix script wrapper around the scala build tool (also referred to, confusingly, as sbt). If while trying to run ./sbt you get strange '\r' errors, install the cygwin package dos2unix, and then run it on the sbt file. If you run into any "which: no curl in..." or "which: no wget in..." errors, go back to the cygwin installer, find those packages such as wget, and then install those programs.
By the way, the last thing the scalatra-sbt script runs is the Scala build tool. The Scala build tool sbt itself has many reported issues with cygwin's default configuration, so you will likely need to do more research. Depending on what issues you're running into on your specific setup, you may need to make changes to the end of the ./sbt script to adjust the parameters used to launch the Scala build tool.
I am new to Linux. I am trying to develop ROS application using eclipse. I don't understand the below which is provided in ROS website. Can you explain this in more simple way, So that I can configure my eclipse after downloading from eclipse.org.
Reusing your shell's environment
For building and running ROS programs from inside IDEs, the ROS
enviroment has to be set up. All IDEs might have a config for that,
but running your IDE from your ROS-sourced shell should be the easiest
way, avoiding inconsistency.
Likewise, you can enhance your IDE's launcher icon to load your shells
environment. E.g., replace its command eclipse with
bash -i -c "eclipse". This will make bash source
~/.bashrc, in which ROS has to
be sourced and parameterized, and start that IDE.
use following commands:
cd <your_catkin_workspace>
catkin_make --force-cmake -G"Eclipse CDT4 - Unix Makefiles"
cd build
cmake ../src -DCMAKE_BUILD_TYPE=Debug
now you can import your project to eclipse
after that you can create a desktop application entry for eclispe:
sudo vim /usr/share/applications/eclipse.desktop
[Desktop Entry]
Type=Application
Terminal=false
Icon=<path_to_your_eclipse_dir>/icon.xpm
Exec=bash -i -c "source /opt/ros/hydro/setup.bash && source $HOME/workspace/<your_catkin_workspace>/devel/setup.bash && <path_to_your_eclipse_dir>/eclipse"
Comment=IDE
Name=eclipse
Comment=IDE
It seems that a wiki was published about this subject here
Put simply, the lines you listed are suggesting you run your IDE (eclipse) from a terminal which has already been sourced. So for instance, if you have a package called mypackage, you might type in a terminal:
cd ~/mypackage
source devel/setup.bash
eclipse
The first line is just however you get to your package, the second line sets up environmental variables for you (like changing your PATH), then you can run eclipse with all of those already setup so you don't have to configure your package in eclipse 100% manually.