Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
I'm not a complete beginner with Linux but I'm using Debian to familiarise myself with it for work.
I have a few quick questions:
To run a binary from a terminal, does it have to be in /bin/? What if it has dependencies, must they also go in /bin/?
I'm used to installing things on Windows by clicking 'next' a lot. If I download a .tgz and it contains an .exe along with several folders, exactly how is it installed?
Is uninstalling in Linux as simple as removing the files, or are there registry style devices that must be modified?
I know these will have been asked before but I cannot get good, clear answers written from a noob friendly point of view. Thanks!
To run a binary from a terminal, does it have to be in /bin/? What if it has dependencies, must they also go in /bin/?
To run a binary just run it from the terminal and see if it works. If it has dependencies they will usually be found automatically or check the readme.
I'm used to installing things on Windows by clicking 'next' a lot. If I download a .tgz and it contains an .exe along with several folders, exactly how is it installed?
Try to double click the .tgz file first then extract and view the README.
Is uninstalling in Linux as simple as removing the files, or are there registry style devices that must be modified?
Depends which Linux OS you are using. Ubuntu is very simple and has a simple interface just like Windows for uninstalling apps.
Not every binary will be in /bin or /usr/bin. To run them from the command line you would set the PATH env var to the directory where executables live. For example, if you create a dir /home/users/foo/bin then set the PATH like so:
export PATH=${PATH}:/home/users/foo/bin
After that, you just type the name of the executable into the shell and the full path is found by searching the directories listed in the PATH.
A .tgz should not contain a .exe since that is a Windows specific executable. Typically, executable on Linux do not have an extension.
No, there is no registry under Linux. That specific insanity is only found under Windows.
1) An executable can be anywhere in directories specified in PATH variable, and you also can run an executable from any location by specifying path to it (if it's in current directory, then write ./<exename>).
2-3) Debian has its own package management system, usually software is installed/uninstalled using sudo apt-get install <package> or sudo apt-get remove package (I recommend reading about apt-get and sudo). Instead of Windows registry, there are many small configuration files in Linux, and some software makes changes to them so it should be carefully uninstalled (but Debian package management usually handles these cases well).
Related
I installed tcl to learn it, however, I installed all the files in the wrong location. I am trying to uninstall it, But the uninstall file does not work. I am trying to carry out the instructions form their website:
To uninstall ActiveTcl, run the "uninstall.tcl" script that is located in the directory where you extracted the ActiveTcl archive. Note that you must use the "wish" in the distribution you wish to uninstall. For example:
% /path/Tcl/bin/wish /path/Tcl/lib/ppm/log/ActiveTcl/uninstall_ActiveTcl.tcl
stored, by default, in the directory /lib/ppm/log/ActiveTcl. You must use the wish interpreter from the distribution you wish to uninstall. Ensure that you do not run the uninstall script from a directory that will be removed during the uninstallation.
For example:
% /path/Tcl/bin/wish /path/Tcl/lib/ppm/log/ActiveTcl/uninstall_ActiveTcl.tcl
Note: if you are uninstalling both ActiveTcl and Tcl Dev Kit, uninstall Tcl Dev Kit before uninstalling ActiveTcl.
There is no uninstall_ActiveTcl.tcl. I do see an "uninstall" file but it does not have an extension, and I do not know how to run it.
Any help is appreciated
Thank you
Try editing the file to a uninstall.tcl file and see if that works. Take a back-up first though. Because we might need that file later
I re-installed it in a new location, compared the files that were installed between the old and the new location and deleted the file sin the old location. Unfortunately I could not delete many of the hidden files, as I did not know if they were there originally or if they belonged to Tcl. I am really surprised and disappointed there is no easy way to uninstall tcl properly.
I strongly suspect that you should uninstall ActiveTcl as follows:
Open a command prompt
Change directory to where you found the install file - e.g.
$ cd path_to_Tcl_installation/bin
Run the file
$ ./uninstall
On linux systems, you don't need any particular file extension in order to be able to run a file.
I don't know CentOS but a little googling led me to a forum thread that describes how to open a command prompt.
Good luck
Once a program is installed in Linux, sometimes I find out that it is easier to put in a different location. In general, what is the significance of the location of the files of an installed program on Linux?
Often the advice on the internet is to add the (wrong or inconvenient) paths to environment variables. I'd much rather move the files to locations where they are automatically found by commands and programs.
One recent example is site-packages of Python. My Python did not appear to check the PYTHONPATH variable, moving the libraries there to the Python2.7/ directory worked well.
Now Ia m facing the same issue with OpenCV.
I also wonder why Linux installation does not prompt (like Windows) for the desired installation directory and why, so often, things wind up in places where they don't work?
In general, programs are installed in /usr/bin (for binaries) and /usr/lib, or a specific path to that specific linux distro, so that any program that you install that uses a specific library/program will search in that path for it. If you install a program in a different path, let's say /home/user/program, it will be installed locally and other programs won't be able by default to access it.
You can install any program wherever you want. However, it is good use to use the repo and install them in the general path.
I don't know how you install programs, but I use apt-get and dpkg on Ubuntu. You can also install some python modules this way.
Generally you are supposed to use the package system provided by your distro (IMHO).
If you do not use packages then you are on your own.
About PYTHONPATH. Did you add it to your .bashrc and made sure that it was set in the terminal you are using?
Also please see:
http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard
Consider these 4 pieces of software:
COBRA 2.05
LibSBML 5.10
MATLAB R2013a (Also known as 8.1, 64-bit; MATLAB no longer supports 32-bit Linux anyway)
A 64-bit Linux OS (such as Ubuntu 14.04 or the latest Mint but not restricted to them)
Intro
The COBRA toolbox is an optimization suite that runs on top of MATLAB aimed at the development of MATLAB code for metabolic network modelling. Such a "network" is a system of equations that can have a very large number of equations and variables (such as thousands). Therefore, routines to read and write those large models according to some format specification are a must-have, and COBRA uses the standard SBML for that.
Problem
Unlike the Windows versions, the Linux binary packages do not integrate well out-of-the-box: to begin with, the pre-compiled Linux binary of libSBML (open-source) available for download does not come with MATLAB support. If one tries to use the pre-compiled libSBML, COBRA won't find the "MATLAB bindings" and therefore won't be able to, for example, read and write SBML XML files from the disk in a m-script.
The question
What needs to be done to make COBRA 2.05 running on top of MATLAB R2013a under Linux (Ubuntu 14.04 or the latest Mint, but this is not likely distro-specific) able to read and write SBML XML files? In other words, what needs to be done system-wide to make COBRA pass its own testSBML test?
This is how I got it working and what I could learn from all the hassle regarding how my Linux box works. I hope I am not forgetting/missing/mistaking anything.
1. MATLAB
1.1. Install MATLAB
Install it in its default location (you will need root access for this), don't be stubborn like I tried to be. Why:
1.1.1. Integration
It is very likely you will want to install some other software that uses the MATLAB framework at some point, and in the real world software doesn't always find other software even if you know how to tell it where to look for.
1.1.2. Make your life easier
Even though it seems like a good idea to install a big software in a place where you have lots of available space and that you can use in multiple machines (specially in Linux, which doesn't have that abomination called Registry, and has symbolic links), that would only perhaps be a good idea - apart from item 1.1.1 - if that place is a partition with a Linux filesystem, since at some point, some executable/script will need execution permission, and mounting the entire partition with execution permission for all its files is rather unsafe. Therefore, do not put MATLAB in an NTFS partition of an external HD; perhaps creating a Linux partition in the external HD just for Linux-specific stuff could work for this matter, but how much hassle is that?
1.2. Setup MATLAB so people and other software can launch it
Even though I have seen somewhere that the MATLAB installer eventually shows an option to create symbolic links in the system path for convenience, it didn't in my case. But that is OK, since I would have to replace the symbolic link /usr/local/bin/matlab by the following shell-script (same path, same filename) anyway:
#!/bin/sh
export LD_LIBRARY_PATH=/usr/local/lib:/usr/lib/x86_64-linux-gnu:$LD_LIBRARY_PATH
exec /usr/local/MATLAB/R2013a/bin/matlab $*
OBS: That LD_LIBRARY_PATH is needed for MATLAB to find SBML bindings later and to be able to use them. Also, if you install some third-party solver such as TOMLAB, you will most likely need to add some more paths in this little launcher script.
OBS 2: In my case, the installation script didn't automatically create any launchers or shortcuts, but I have found an iconless and extension-less Matlab 8.01 file and a matlab icon as a png file, and that first file was a template .desktop file that I could edit to fit my needs and put in /usr/share/applications so the Unity Dash would find it. The contents of this Matlab.desktop file are:
[Desktop Entry]
Type=Application
Icon=/usr/local/MATLAB/R2013a/Matlab.png
Name=Matlab 8.01
Comment="Start Matlab 8.01"
Exec=/usr/local/MATLAB/R2013a/bin/matlab -desktop
Categories=Development;
Name=Matlab 8.01
GenericName=Matlab 8.01
Comment="Start Matlab 8.01"
2. libSBML
2.1. Install libSBML
libSBML is provided by a deb package specific for Ubuntu (and for CentOS), and also versions for several flavours of Windows and MacOSX (their home page: http://sbml.org/Software/libSBML). Guess which is the only platform whose binaries weren't compiled with MATLAB support? Linux, of course. That means you will need to compile from source (and that the deb package is therefore useless to you). To compile:
2.1.1. Install dependencies
The dependency libxml2-dev (from software manager or from a terminal):
sudo apt-get install libxml2-dev
2.1.2. Save yourself some time in the future
Usually, one would do configure, make and then make install. But this is not recommended for the same reason as installing anything that doesn't come in a pretty little package: you will loose control of which files went where, and will need to keep the source-code to be able to run make uninstall if you need to uninstall it later. So, install checkinstall and use it to replace the step make install, since checkinstall creates a package for your system that can be later uninstalled or reinstalled just as any regular packaged software (from software manager or from a terminal):
sudo apt-get install checkinstall
2.1.3. Configure the compiling-process
Get LibSBML source code and extract it to some folder. From a terminal, navigate to that folder and configure the compilation:
./configure --with-matlab
OBS: with the with-matlab flag, the configure script will fail it it cannot find an executable whose filename is matlab. If it fails, it outputs that the matlab file could not be found, but the test it performs is actually both for the existence of the file and whether it is executable. So, if the file is in an NTFS partition, configure will fail even if it finds the file, but will tell you the file couldn't be found. You can enforce it to look for the executable in /path/to/matlab/root by passing (it will look for a bin folder inside that path, and for the executable inside that bin folder):
./configure --with-matlab=/path/to/matlab/root
OBS: This will install libSBML in the default location: /usr/local/lib. Again, it is a good idea to just let it install in its default location, but if you need to change it, you can pass the path with the flag: --prefix=/your/installation/path
OBS 2: You might ask why libSBML needs to find and execute matlab to be compiled with support for it: it needs to fire up MATLAB later to build MEX-files (compiled MATLAB code), so I would speculate you wouldn't be able to install libSBML after all if your MATLAB has no compiler to generate MEX-files.
2.1.4. Build and install libSBML
make
checkinstall
VERY IMPORTANT OBS:
I) checkinstall asks for confirmation of the metadata of the package it is about to create. In my case, the string for the version field came by default as "Source" (without the quotes), which caused checkinstall to fail because dpkg (the system tool that actually builds the deb file) failed complaining the version number must start with, well, a number. So, save yourself some time and make sure the string in the version field starts with a number (i.e. "5.10", without the quotes obviously)
II) checkinstall asks if you want to exclude from the future package files that the make install command would put in your home folder and says it is a good idea to exclude them. LibSBML has a test.xml file that it needs to be in the $HOME folder later, or else it won't let you integrate with MATLAB. And even though it tells you a test.xml is missing, it doesn't tell you where that file should be or if that file was something that came with the library. I only noticed it because checkinstall had found a $HOME/test.xml reference earlier (that I excluded from the package, of course) and I had found that odd. So, save yourself some time and exclude $HOME/test.xml from the package generated by checkinstall, and then search for test.xml inside the source-code folder and copy it to $HOME as soon as libSBML finishes being installed by checkinstall.
2.2. Integrate libSBML to MATLAB
Fire up MATLAB, navigate to where the SBML MATLAB-bindings were installed in step 2.1.5 (in my case: /usr/local/lib) and run the file installSBML.m that should be there.
2.2.1. Shared libraries problems
In my case, I had an error due to an old unresolved issue: libstdc++.so.6 not having a reference to GLIBCXX_3.4.15. Turns out that MATLAB was trying to use a libstdc++.so.6.0.13 (libstdc++.so.6 was a symbolic link pointing to this file) that came with it in /usr/local/MATLAB/R2013a/sys/os/glnxa64, which indeed didn't have that reference (one could verify that by issuing:
strings /usr/local/MATLAB/R2013a/sys/os/glnxa64/libstdc++.so.6.0.13 | grep GLIBC
). My system has a libstdc++.so.6.0.19 located in /usr/lib/x86_64-linux-gnu that has that reference, so I enforced MATLAB to use 6.0.19 one by setting the LD_LIBRARY_PATH properly (refer to step 1.2) and also by renaming the libstdc++.so.6 that came with MATLAB to something else so it would not find it and would keep looking until it found my system's. A friend of mine running Linux Mint didn't need to rename anything: for him, setting the LD_LIBRARY_PATH was enough.
2.2.2. Other problems
installSBML.m will fail if it doesn't find that $HOME/test.xml file mentioned in step 2.1.5, regardless of whether the library actually works. It assumes that if it could not test itself using a file that it assumes to be in $HOME, the user shouldn't have the option to install it anyway.
3. COBRA / SBML toolbox
3.1. Setup COBRA
In MATLAB, navigate to <YOUR_COBRA_ROOT_FOLDER_HERE>/external/toolboxes/SBMLToolbox-4.1.0/toolbox and run the file install.m there. You should have all set so it finds the MATLAB-bindings you set up in step 2.2.
3.2. MATLAB setpaths problems
I had to manually edit the file /usr/local/MATLAB/R2013a/toolbox/local/pathdef.m as root to include the folder /usr/local/lib (where libSBML and its MATLAB-bindings are) to make that setting persistent. Every time I restarted MATLAB, its setpath had gone back to the default, no matter if I started MATLAB as root when setting its setpath via the MATLAB GUI.
3.3. Test
Now you have hopefully connected all the dots. Try it: in MATLAB, navigate to <YOUR_COBRA_ROOT_FOLDER_HERE> and issue:
initCobraToolbox
testAll
If you haven't got any third-party solvers installed and configured, it should pass 14 of the 19 tests, including the SBML test (testSBML). Now you can load SBML files into MATLAB and play with them.
I also needed to add a symbolic link from /usr/local/lib/libsbml.so.5 to the MATLAB sys folder by:
sudo ln -s /usr/local/lib/libsbml.so.5 /usr/local/MATLAB/R2014a/sys/os/glnxa64/
This finally made the installation possible.
I installed using Cmake. To do this it is necessary to find the FindMatlab.cmake in the source package and insert the MATLAB path manually!
.............
elseif(EXISTS "/Applications/MATLAB_R2008a.app/")
set(MATLAB_ROOT_PATH "/Applications/MATLAB_R2008a.app/")
endif()
else()
if (EXISTS "/usr/local/MATLAB/R2014a/")
set(MATLAB_ROOT_PATH "/usr/local/MATLAB/R2014a/")
endif()
endif()
..........
FYI, to resolve the shared library issue at point 2.2.1 I needed to install the package matlab-support (in Ubuntu repositories)
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
Just as a preface, sorry if I am missing something obvious. I am mainly a PHP/Python programmer but am doing server config for a friend's startup.
I only have left to install Apache Ant on my friend's Linux VPS server (he wants to compile Android apps on server- just a note I have already somehow manged to get the JDK and LAMP that would also be necessary).
When I did some digging on how to get Ant, this was all I got that really met my needs: http://ant.apache.org/manual/install.html#jpackage
Can someone give me some kind of push on what to do at all? Maybe a wget with the appropriate link? Anything at all is appreciated.
Thanks in advance to all.
Did you search for the package apache-ant in your RPM database?
If you're not using your RPM for installing packages (and why wouldn't you), you can download Ant directly from Apache. (Note that there are directions for JPackage RPMs too. Just in case you change your mind about not using RPMs.
Ant is a Java program, so you must have a Java JDK installed (Ant will run under the JRE, but you couldn't build Java apps with that), and make sure that the java command is in your Path. However, that also means that there is no special version of the Ant binary for each platform, so it's much easier to install.
Download and extract the Ant archive to a suitable directory (/opt or /usr/local or /usr/lib or whatever standard you're using). Inside the archive, when unpacked, will be a bin directory. Those files under bin are mainly shell scripts (the ones that end with *.bat are Windows Batch files, you can ignore those). Just execute those.
I like to symbolically link those files under Apache-Ant's bin directory to a similar name under /usr/local/bin directory. That way, you don't need to put /usr/local/apache-ant-1.8.3/bin in your $PATH.
And that's really about it.
Just follow the "Short Story" section at the top of the page you referenced:
To get up and running with the binary edition of Ant quickly, follow these steps:
Make sure you have a Java environment installed, See System Requirements for details.
Download Ant. See Binary Edition for details.
Uncompress the downloaded file into a directory.
Set environmental variables JAVA_HOME to your Java environment, ANT_HOME to the directory you uncompressed Ant to, and add ${ANT_HOME}/bin (Unix) or %ANT_HOME%/bin (Windows) to your PATH. See Setup for details.
Optionally, from the ANT_HOME directory run ant -f fetch.xml -Ddest=system to get the library dependencies of most of the Ant tasks that require them. If you don't do this, many of the dependent Ant tasks will not be available. See Optional Tasks for details and other options for the -Ddest parameter.
Optionally, add any desired Antlibs. See Ant Libraries for a list.
Note that the links in the list above will give more details about each of the steps, should you need them. Or you can just continue reading the rest of this document.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
In the linux file system, where should user scripts be placed?
I'm thinking specifically python scripts to be called by cron.
the information i got:
/usr/local/sbin custom script meant for root
/usr/local/bin custom script meant for all users including non-root
chatlog snips from irc.debian.org #debian:
(02:48:49) c33s: question: where is the _correct_ location, to put custom scripts
for the root user (like a script on a webserver for createing everything needed
for a new webuser)? is it /bin, /usr/local/bin,...? /usr/local/scripts is
mentioned in (*link to this page*)
(02:49:15) Hydroxide: c33s: typically /usr/local/sbin
(02:49:27) Hydroxide: c33s: no idea what /usr/local/scripts would be
(02:49:32) Hydroxide: it's nonstandard
(02:49:53) Hydroxide: if it's a custom script meant for all users including
non-root, then /usr/local/bin
(02:52:43) Hydroxide: c33s: Debian follows the Filesystem Hierarchy Standard,
with a very small number of exceptions, which is online in several formats at
http://www.pathname.com/fhs/ (also linked from http://www.debian.org/devel/ and
separately online at http://www.debian.org/doc/packaging-manuals/fhs/fhs-2.3.html)
(02:53:03) Hydroxide: c33s: if you have the debian-policy package installed, it's
also in several formats at /usr/share/doc/debian-policy/fhs/ on your system
(02:53:37) Hydroxide: c33s: most linux distributions follow that standard, though
usually less strictly and with more deviations than Debian.
thanks go out to Hydroxide
If you're talking about scripts created by a user that will be run from that users crontab, I typically put those in either a bin or scripts folder in the home directory, or if they're intended to be shared between users, a /usr/local/scripts directory.
For whom it interests, the Filesystem Hierarchy Standard (FHS) is a standards document and still a very good read. I describes the foundation for almost any Linux distribution and is officially endorsed e.g. by Debian and the Linux Standards Base (LSB).
You won't find any positive answer for that question, though, since ... it's not defined ;-). Only thing I can say: Don't put in /bin (neither in /usr/bin). /usr/local/scripts is unusual as well. $HOME/bin seems to be an acceptable place, iff the script is only used by this single user.
I'm a strong beleiver that if a file is made by a user, it goes in his user directory (/home/username) if he didn't make it then it gets more complicated. I have in the past just put them in either /usr/local/bin, /bin, or /usr/local/scripts, I'm not sure about etch, but you need to check to make sure that /usr/local/scripts is actually in Cron's $PATH.
The Debian guide can be quite useful when it comes to Ubuntu:
Normally, programs install themselves in the /usr/local subdirectories. But, Debian packages must not use that directory, since it is reserved for system administrator's (or user's) private use
/usr/local/bin seems to be acceptable according to the guide.
Personally I put my scripts in $HOME/.scripts.
I wish that LSB would specifically address this question though.
How about /home/username/bin?
Add ~/bin to $PATH and make the script executable with chmod +x filename.
personally I prefer
/home/username/.bin
This way the bin folder is hidden but you can still add it to the PATH and execute all scripts with the x-bit inside.
I like my home directory to be clean (at first glance) with very few folders.
You can also add paths to your crontab file as shown in a previous cron-related question.