I am having trouble getting Openfire to work. I done the following:
[root#jiaoyou logs]# which java
/usr/bin/java
and I've run this command:
ln -s /usr/bin/java /opt/openfire/jre/bin/java
but when starting Openfire, it still says:
cannot run command `/opt/openfire/jre/bin/java': No such file or directory
It seems like a permission issue, but I don't know how to fix that.
This was solved for me, in CentOS6 64bit, using the following commands:
cd /opt/openfire/jre/bin
cp java java.bak
rm java
ln -s /usr/bin/java java
service openfire start
If you're on a 64-bit machine, you should install zlib package for 32-bit architectures.
For Redhat/Centos, use:
yum install -y zlib.i686
/usr/bin/java is just a shell script that runs the actual binary. If you don't have the JAVA_HOME environment variable set correctly, it might not be able to locate the binary if invoked through a symlink like that.
Another thing to keep in mind is that some distros of Linux put /usr/bin/java in place even though you haven't installed the Sun JRE. Don't bother trying to use the GNU version of Java, it's rubbish. Do you know if the Sun JRE is installed or not? What does "java -version" tell you?
I think the correct answer is using the right command to start openfire. I have found that "service openfire start" actually doesn't work.
I attempted the above mentioned method of removing the java executable from opt/openfire/jre/bin and all that did was force me into reconfiguring all of my current openfire settings. Thank god I made that java.bak file.
I believe the proper method to stop|start|restart is from /opt/openfire/bin and run ./openfire start or from anywhere "/opt/openfire/bin/openfire start"
At least that's what worked for me.
Related
So I follow the commands on the website.
I open one windows and I used the command: sudo make qemu-gdb. And it asked me to use another terminal to start gdb.
When I used the gdb provided by the Linux system. It shows this error message:
.gdbinit:2: Error in sourced command file:
Undefined item: "riscv:rv64".
What should I do to fix the issue?
You need to use riscv64-unknown-elf-gdb instead of gdb. It would be installed in your system when you install riscv-gnu-toolchain specified in xv6 site.
use /usr/bin/gdb-multiarch instead
riscv64-unknown-elf-gdb didn't come with the riscv-gnu-toolchain for me.
Using gdb-multiarch in ubuntu 18 works for me.
Your gdb version should be 8.3 and later
Replace all gdb with riscv64-unknown-elf-gdb when you are following the textbook and you should be good to go.
You can also run
riscv64-unknown-elf-gdb --version
to check the availability of this command. If something is not right, see this page to re-install the toolchain. (Remember to make clean before re-making to clean the temporary files.)
I have started learning groovy and I just came across the SDKMAN utility.
To give it a try I folllowed the installation guidelines at the official site of sdkman and tried to run the below command to install sdkman on Windows 10 :
set SDKMAN_DIR="E:/sdkman" && curl -s "https://get.sdkman.io" | bash
But I donot see any sdkman folder present in my E drive.
When I try to re-run the command it says :
Looking for a previous installation of SDKMAN...
SDKMAN found.
======================================================================================================
You already have SDKMAN installed.
SDKMAN was found at:
"E:/sdkman"
I am just confused as to why am I not able to see it with my eyes. I have even tried enabling view hidden items.
Tried to execute which sdk. but it clearly says which: no sdk in (..
...
has anyone else experienced similar issue. Any help is highly appreciated.
which bash implementation are you using under windows? cygwin? gitbash?
I believe at least in gitbash that the path syntax is /e/sdkman/, i.e. you would do:
export SDKMAN_DIR="/e/sdkman" && curl -s "https://get.sdkman.io" | bash
but it's been a long time since I was on windows and I suspect this is bash-implementation specific (i.e. it might differ between cygwin and gitbash for example).
If this assumption is correct, the syntax you were using might have created a directory called E:/sdkman under your user's home directory or whatever directory you happened to be in when you ran this. Just guessing here, but worth a look.
Composer doesn't run correctly in Cygwin if you try to install it "globally".
Putting composer.phar into /usr/local/bin/composer, then trying to run it will result in the error:
Could not open input file: /usr/local/bin/composer
Just tripped over the same problem and found a solution. Posting it here, just in case I'll ever have to look it up again.
Set up a bin directory right under /home/my-username:
cd ~
mkdir bin
Move the composer.phar (or any other of those nifty new PHP imps that are on the rise)
into the ~/bindirectory and make sure to set it's execution bit:
# Notice how I got rid of the superfluous `.phar` extension
mv /path/to/composer.phar ~/bin/composer
chmod +x ~/bin/composer
Tell cygwin to include your ~/bin directory in the search path:
Open up the file ~/.bash_profile and uncomment the following paragraph ...
# Set PATH so it includes user's private bin if it exists
if [ -d "${HOME}/bin" ] ; then
PATH="${HOME}/bin:${PATH}"
fi
Now, for the most important part:
A wrapper script that helps Win's native PHP resolve Unix style paths (which is causing
the problem after all as Windows doesn't know how to handle /cygdrive/... paths).
cd ~/bin
touch php
chmod +x php
After editing the wrapper script ~/bin/php should read:
#!/bin/bash
# e.g. php="/cygdrive/c/Program Files (x86)/php/php.exe"
php="/path/to/php.exe"
for ((n=1; n <= $#; n++)); do
if [ -e "${!n}" ]; then
# Converts Unix style paths to Windows equivalents
path="$(cygpath --mixed ${!n} | xargs)"
case 1 in
$(( n == 1 )) )
set -- "$path" "${#:$(($n+1))}";;
$(( n < $# )) )
set -- "${#:1:$((n-1))}" "$path" ${#:$((n+1)):$#};;
*)
set -- "${#:1:$(($#-1))}" "$path";;
esac
fi
done
"$php" "$#"
Now restart your shell and it should correctly invoke the PHP interpreter whenever it
stumbles upon a #!/usr/bin/env php shebang. Simply issue a:
composer --help
How about this one?
In ~/.bashrc, add: alias composer='php c:\\your\\path\\to\\composer.phar'
Restart cygwin or reload the bashrc by running source ~/.bashrc
Works for me using both Cygwin's native php.exe and XAMPP's Windows-specific one.
I think what might work is to build a proxy instead:
Put composer.phar in /usr/local/bin/composer.phar
Create a bash proxy as /usr/local/bin/composer with the following:
#!/bin/sh
c:/path/to/php c:/path/to/composer.phar $#
chmod +x /usr/local/bin/composer
Try this:
Install Cygwin PHP and use it to run composer in Cygwin.
You can choose one of two ways to work fine with PHP+Composer in Cygwin:
Install Cygwin PHP and install composer.phar in Cygwin.
Install Windows PHP and install Winodows Composer, then call then from Cygwin. (Windows XAMMP+Composer with alias in cmd)
Your problem is caused by that Cygwin Composer is ruining by Windows PHP on Cygwin, so it can not recognize the file path.
After install Cygwin PHP, the composer will integrates with Cygwin PHP then fit to Cygwin's filepath.
Cygwin PHP extensions for composer usage:
php
php-json
php-mbstring
php-phar
php-zip
php-posix
You can install other PHP extension when composer's package is needed such as php-xmlwriter, php-tokenizer, php-ctype.
Installation commands guide:
If you have already installed apt-cyg, there are installation command above:
apt-cyg install php php-json php-mbstring php-phar php-zip php-posix
apt-cyg install php-xmlwriter php-tokenizer php-ctype
Then install Composer via Cygwin PHP:
php -r "copy('https://getcomposer.org/installer', 'composer-setup.php');"
php composer-setup.php
php -r "unlink('composer-setup.php');"
chmod +x ./composer.phar
mv ./composer.phar /usr/bin/composer
composer -v
Conclusion
I recommend using Windows PHP + Windows Composer, and call then in Cygwin, it because the Cygwin PHP is not much stable than Windows PHP.
I had the same problem. After reading the final instruction from composer installer, it says that the $PATH variable should be reloaded. I rebooted my computer and then linked the Composer bin to /usr/local/bin.
First locate the composer bin :
/cygdrive/c/ProgramData/ComposerSetup/bin/composer
Then according to Seldaek answer, after trying a non-working symlink, I did :
nano /usr/local/bin/composer
#!/bin/sh
/cygdrive/c/ProgramData/ComposerSetup/bin/composer $#
chmod +x /usr/local/bin/composer
And it's working.
What I did (very simple):
Install Composer normally with the Windows installer
Open a Cygwin console an type composer you will see something like Could not open input file: /c/route/to/your/composer/installation/bin
Create an alias composer='composer.bat' on your bash profile or bashrc or whatever
Done
I'm running Windows 8.1
I was having this issue. Most of the responses were over my head but I fixed it with no problems.
Step 1) Reinstall Composer globally as per https://getcomposer.org/download/
Step 2) Leave it alone. All the special stuff you want to do, don't do that.
Step 3) Download the latest setup-xxx.exe from https://cygwin.com/
Step 4) Click it with your mouse.
NOTE: During step 5 you will feel a sudden urge to read instructions, browse the web for info and start checking little boxes on the menu. Don't do that.
Step 5) Click 'next' until it stops asking. It will look at your existing
settings, fix things up and add any missing dependencies.
This worked for me.
Getting composer to work globally inside Cygwin is a pain in the butt...
The solutions I have come up with:
Don't use it globally. If you are using the PHP CLI from a Windows installation, it won't recognize the Linux paths that Cygwin uses.
What I have done is put it in the base directory of all the projects I use composer with, and do ../composer.phar to run it.
It works fine this way, and it's almost globally available...
Download, and compile your own PHP binaries within Cygwin... Yea, kind of a overkill.
I solved the problem like this in a Cygwin/XAMPP setup:
Install composer.phar to XAMPP's php directory
Create an executable Bash script named composer in XAMPP's php directory:
#!/bin/bash
script_dir=$(cygpath -w $(dirname $0))
php "$script_dir/composer.phar" $#
It's important to use cygpath -w to convert the path to a path in Windows form.
Make sure XAMPP's php directory is accessible in Cygwin's $PATH:
$ export PATH=$PATH:/cygdrive/i/dev/server/xampp/php
Now it's possible to call composer from anywhere you like without problems:
$ composer -V
Composer version 264f433ca3f007d39568b3722b4bf418f58ba15b
I fixed it by adding a /usr/local/bin/composer file:
nano /usr/local/bin/composer
with the following content:
#!/bin/bash
/cygdrive/c/wamp/bin/php/php5.4.3/php "C:\wamp\bin\php\php5.4.3\composer"
Basically, you have to call PHP with a Windows style path, not a cygwin path.
The easiest way is to install composer using the Windows installer from their website and then copy the two files 'composer' and 'composer.phar' from "C:\ProgramData\Composer" into a directory which is in the PATH variable. E.g. you could copy the files into the /bin/ directory of cygwin. Afterwards you can again uninstall the "Windows version" of composer.
Update! This is what I did:
Install PHP and needed modules from the Cygwin Ports project
Download the latest composer snapshot
Rename 'composer.phar' to 'composer' and save it to /usr/local/bin
Open /bin/dash.exe and run '/usr/bin/rebaseall'
Also if 4. gives you an error, composer should run now
I suggest you use babun, it is based cygwin, but you can install package by pact, you can do this:
pact install php php-json php-phar
php -r "readfile('https://getcomposer.org/installer');" | php
then enjoy yourself.
I was having trouble getting Composer to work in Cygwin and none of the solutions above were resolving my problem. Eventually I stumbled across this comment in the Composer github bugs discussion:
Yeah TBH using php from cygwin isn't a great idea, cygwin is just too different an environment. Too many hacks that create failures.. In any case closing here as there isn't much we can do I'm afraid :)
I don't know precisely where composer/Cygwin/php was tripping up, but, broadly, my problem was that I had two conflicting installations of PHP in environmental variables, one from an installation of WAMP, and another installed with Cygwin. The Cygwin PHP installation seemed to be struggling with some sort of path issue. I removed it, using only the WAMP PHP, and composer ran in Cygwin just fine.
I am trying to install node.js. I followed this tutorial and i am stuck in the middle.
When I write ./configure in my cygwin terminal it says "cygwin not supported". Please help me out
Thanks in advance.
Node in my experience runs fine in cygwin, what Node usually has EINVAL errors in seems to be MINTTY which is a terminal emulation 'skin' that is default to cygwin. I still am not sure why these EINVAL errors happen 100% but the following are the steps and tricks I use to get node working.
In my /cygwin/home/{username}/.bashrc I add node to path so cygwin can find it
export PATH=$PATH:"/cygdrive/c/Program Files/nodejs/"
If you run a 32 bit version of node:
export PATH=$PATH:"/cygdrive/c/Program Files (x86)/nodejs/"
Then to make npm run without windows to linux issues I launch cygwin in admin mode then run:
dos2unix '/cygdrive/c/Program Files/nodejs/npm'
At this point running files and most npm packages will run in MINTTY just fine, although every once and awhile you will run into EINVAL issues with certain npm packages as karma. Also you will not be able to run the interpreter directly in MINTTY, anytime I want to do these things I run:
cygstart /bin/bash
This will open a native cygwin bash.exe window, from here you run the interpreter or an any troubling package command that results in a EINVAL. It slightly sucks you have to do this but I rarely use this day to day, and I love MINTTY too much to not use it.
Also note that you can run any one line node code in MINTTY by just running something like:
node -e "console.log('hello node')"
As a simpler derivative of troy's answer for those just looking to install NPM packages:
Install Node.js with the Windows installer package.
Add it to the PATH with export PATH=$PATH:"/cygdrive/c/Program Files/nodejs/" (obviously replacing the path to Node.js's installation directory with where you installed it).
There's a current bug in the Windows version that can be fixed by running mkdir -p ~/AppData/Roaming/npm. This is a bug for all of Windows and not just Cygwin. At some point of the future, you won't have to do this anymore, but the command shouldn't have any negative side effects.
Test it. Eg, npm install pretty-diff -g.
In order to be able to run the newly installed software, you'll need to add the install locations to your PATH. You can find these with npm bin -g and npm bin (the -g flag is the "global" installation location).
Not really anything special that you have to do to get it to run in Cygwin (although I can't say if everything works).
Use Console2, it allows you to run create tabs of CLI shells. It seems running cygwin inside console2 allows me to use node REPL just fine. I have no idea why :P
Follow this guide to add cygwin to console2:
http://blog.msbbc.co.uk/2009/11/configuring-console-2-and-bash-with.html
With Bjørn's suggestion (using Console2) and Soyuka's alias (steps here), my node.js v0.10.13 and npm v1.3.2 are now working under Babun v1.02, a Cygwin distribution.
For windows, Just run bash.exe in cmd, so that you could have a bash work around with cmd console directly, which could support ALL NODE WORKING PERFECTLY.
C:\Users\郷>bash
郷#CHIGIX ~
$ node
>
I'm using this wrapper in /usr/local/bin/node (note no extension!)
#!/bin/sh
_cmd="$(cygpath -lw -- "$1" )"
shift
"/proc/cygdrive/C/Program Files/nodejs/node.exe" "$_cmd" "$#"
This is far from perfect, as Node do not understand Cygwin directory tree, but works relatively well with relative names.
From Windows, run Cygwin.bat (instead of Cygwin Terminal) then in that run node: see and reply on this answer on this effectively-same question asked 1.5 years later.
Grab and run the node.js Windows installer.
In the Cygwin prompt type node
See if it works.
I installed JDK using apt-get install but I don't know where my jdk folder is. I need to set the path for that. Does any one have a clue on the location?
This depends a bit from your package system ... if the java command works, you can type readlink -f $(which java) to find the location of the java command. On the OpenSUSE system I'm on now it returns /usr/lib64/jvm/java-1.6.0-openjdk-1.6.0/jre/bin/java (but this is not a system which uses apt-get).
On Ubuntu, it looks like it is in /usr/lib/jvm/java-6-openjdk/ for OpenJDK, and in some other subdirectory of /usr/lib/jvm/ for Suns JDK (and other implementations as well, I think).
Debian is the same.
For any given package you can determine what files it installs and where it installs them by querying dpkg. For example for the package 'openjdk-6-jdk': dpkg -L openjdk-6-jdk
update-java-alternatives -l
will tell you which java implementation is the default for your system and where in the filesystem it is installed. Check the manual for more options.
$ which java
should give you something like
/usr/bin/java
This question will get moved but you can do the following
which javac
or
cd /
find . -name 'javac'
Use find to located it. It should be under /usr somewhere:
find /usr -name java
When running the command, if there are too many "Permission denied" message obfuscating the actual found results then, simply redirect stderr to /dev/null
find /usr -name java 2> /dev/null
Another best way to find Java folder path is to use alternatives command in Fedora Linux (I know its for Ubuntu but I hit this post from google just by its headline). Just want to share incase people like me looking for answers for fedora flavour.
To display all information regarding java
alternatives --display java
Three Step Process:
First:
open Terminal->$ whereis java
it would give output like this:
java: /usr/bin/java /usr/share/java /usr/share/man/man1/java.1.gz
Second:
ls -l /usr/bin/java
It would give output like this:
lrwxrwxrwx 1 root root 22 Feb 9 10:59 /usr/bin/java -> /etc/alternatives/java
Third:
ls -l /etc/alternatives/java
output is the JDK path:
lrwxrwxrwx 1 root root 46 Feb 9 10:59 /etc/alternatives/java -> /usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java
Simple, try it:
It's /usr/local/java/jdk[version]
This question still seems relevant, and the answer seems to be a moving target.
On my debian system (buster):
> update-java-alternatives -l
java-1.11.0-openjdk-amd64 1111 /usr/lib/jvm/java-1.11.0-openjdk-amd64
However, if you actually go look there, you'll see there are multiple directories and symbolic links placed there by the package system to simplify future maintenance.
The actual directory is java-11-openjdk-amd64, with another symlink of default-java. There is also an openjdk-11 directory, but it appears to only contain a source.zip file.
Given this, for Debian ONLY, I would guess the best value to use is /usr/lib/jvm/default-java, as this should always be valid, even if you decide to install a totally different version of java, or even switch vendors.
The normal reason to want to know the path is because some application wants it, and you probably don't want that app to break because you did an upgrade that changed version numbers.
the command: sudo update-alternatives --config java will find the complete path of all installed Java versions
On Linux Fedora30 several versions of the full java JDK are available, specifically package names:
java-1.8.0-openjdk-devel.x86_64
java-11-openjdk-devel.x86_64
Once installed, they are found in: /usr/lib/jvm
To select the location/directory of a full development JDK (which is different from the simpler runtime only JRE) look for entries:
ls -ld java*openjdk*
Here are two good choices, which are links to specific versions, where you will have to select the version:
/usr/lib/jvm/java-1.8.0-openjdk
/usr/lib/jvm/java-11-openjdk
on OpenSUSE 13.1/13.2 its: /usr/lib64/jvm/java-1.6.0-openjdk-(version-number)
version-number can be 1.7.x 1.8.x etc. check software manager witch version you have installed...
André
This is the best way which worked for me
Execute this Command:-
$(dirname $(readlink $(which javac)))/java_home
below command worked in my debain 10 box!
root#debian:/home/arun# readlink -f $(which java)
/usr/lib/jvm/java-11-openjdk-amd64/bin/java