I am trying to run a program from command line in ubuntu and I have a directory that is in the usr/include/ directory that I need to remove so that it will run. How can I do this from command line?
rm -r /usr/include/...
Just use that. But if you need to do that, there is something wrong with your program. If a package installed the directory, use:
sudo apt-get purge package-name
All in all, the directories directly under /usr are under the charge of the package manager, and if you want to do things without that, use the /usr/local dir. Changing other programs resources is a bad idea. Also, don't run anything you don't have to with sudo. That will end badly. And what program would require the removal of a dir in /usr/include?
Related
Hi I'm very new to Linux..
Once I have changed ownership of /usr my sudo command failed working ..
Once I changed ownership of /var some other things broke ..
1: I just want to know which are folders where one should never change it's default ownership..
2: what if someone gets permission_denied for /var during installing some packages .. chmod or chown should be used ...
I would never change the ownership in folders unlike /home/* /opt/. Sometimes you have to change the owner if you put your own stuff to /etc/, but you should now what to do.
To install software, even in Ubuntu use the provided tools, 'apt' and 'dpkg' for example. Often the installation needs root rights. Give them with the usage of and additional 'sudo'.
# f.e. installation of a command line browser
sudo apt install w3m
I want to create a shell script that uses the Expect library however Expect is not installed on any of the systems where I want to run the script. I also cannot install the library on these systems either. Can I build Expect from source and then put in same directory as the script? How would you go about this?
Yes you can, and it's not difficult.
Download Expect sources from https://sourceforge.net/projects/expect/files/latest/download?source=files
Unpack sources
gunzip expect.tar.gz
tar -xvf expect.tar
This will create a directory containing the Expect distribution. Change to that directory and
Configure sources for compilation:
./configure --prefix=~/
With --prefix parameter you specify where Expect should be installed. ~/ in my example is a shortcut for current user home directory, so it will be installed locally for your user only and you don't need root privileges this way to install it. In case you have root privileges and want to install it system-wide, you can omit --prefix parameter.
Compile Expect:
make
And install it:
make install
And that's it :)
I've recently had to compile a program (Riak) from source since they don't have a repo available for Ubuntu 16.04 yet.
I've compiled the program and copied it to /opt/riak where it works fine.
Since this program requires sudo privileges, I've decided to symlink /opt/riak/bin/riak to /usr/local/bin/riak instead of adding the variable to the path via a profile.d file (because in order to work with sudo I'd have to remove env_reset from /etc/sudoers which I rather not do).
The error I get is the following:
/usr/local/bin/riak: 8: .: Can't open /usr/local/bin/../lib/env.sh
Shouldn't the symlink execute the file from the original's working directory? Is there a way to make it work?
The error message is almost self explanatory. Apparently the riak executable is trying to find a file called env.sh using a path relative to its own, namely ../lib/env.sh. Originally, this would resolve to the following path: /opt/riak/bin/../lib/env.sh, which is the same as /opt/riak/lib/env.sh. But now is trying to find the file at /usr/local/bin/../lib/env.sh which is the same as /usr/local/lib/env.sh and obviously the file is not there.
You have the following options (in order of preference):
Leave the program in /opt and invoke it from there
Leave the program in /opt and create a small wrapper shell script in /usr/local/bin that calls the original executable (see at the end of this post).
Recompile the program passing the right parameters to its configure script (e.g. --prefix=/usr/local) so that it works from /usr/local.
I would recommend against option 3; I prefer to let the /usr directory be managed by the distos package manager. If I have to compile something myself, I prefer to put it in a dedicated directory bellow /opt. This way, if I want to remove it later on, I can just delete that directory.
Example wrapper script for option 2:
#!/bin/bash
exec /opt/riak/bin/riak "$#"
Archlinux.
I downloaded mtools, which includes mcopy, which is what I'm after. The instructions in the INSTALL file say do this:
# ./configure
# make
These worked fine, now I have a bunch of .o files and of course executables.
What do I need to do, so I can just type
# mcopy
and have it run? Since I don't have it "installed" right now, doing that just says
-bash: mcopy: command not found
The usual linux build sequence is
./configure
make
make check
sudo make install
make check attempts to validate if the build took place correctly; not all Makefiles have it but many do. Note you will need sudo make install to do the install in the usual system directories if you are not root.
You can determine which of these options is available for your particular Makefile by
cat Makefile
and reading the labels on the left of the file.
You could create a symbolic link to the application in your /usr/bin folder like
ln -s /fullpath/to/app /usr/bin/aliasnameforapp
Then you can simple call aliasnameforapp from anywhere.
I have a debian package that I built that contains a tar ball of the files, a control file, and a postinst file. Its built using dpkg-deb and it installs properly using dpkg.
The modification I would like to make is to have the installation directory of the files be determined at runtime based on an environment variable that will be set when dpkg -i is run on the deb file. I echo out the environment variable in the postinst script and I can see that its set properly.
My questions:
1) Is it possible to dynamically determine the installation directory at runtime?
2) If its possible how would I go about this? I have read about the rules file and the mypackage.install files but I don't know if either of these would allow me to accomplish this.
I could hack it by copying the files to the target location in the posinst script but I would prefer to do it the right way if possible.
Thanks in advance!
So this is what I found out about this problem over the past couple of weeks.
With prepackaged binaries you can't build a debian package with a destination directory dynamicall determined at runtime. I believe that this might be possible if installing a package that is built from source where you can set the install directory using configure. But in this case since these are embedded Ubuntu machines they don't have make so I didn't pursue such an option. I did work out a non traditional method (hack) for installing that did work. Since debian packages simply contain a tar ball relative to / simply build your package relative to a directory under /tmp. In the postinst script you can then determine where to copy the files from the archive into a permanent location.
I expected that after rebooting and the automatic deletion of the subdirectory under /tmp that dpkg might not know that the file package existed. This wasn't a problem. When I ran 'dpkg -l myapp' it showed as still installed. Updating the package using dpkg/apt-get also worked without a hitch.
What I did find is that if you attempted to remove the package using 'dpkg -r myapp' that dpkg would try and remove /tmp which wasn't good. However /tmp isn't easily removed so it never succeeded. Plus in our situation we never remove packages but instead simply upgrade them.
I eventually had to abandon the universal package due to code differences in the sources resulting in having to recompile per platform but I would have left it this way and it did work.
I tried using --instdir to change the install directory of the package and it does relocate the files but dpkg fails since the dpkg file can't be found relative to the new instdir. Using --instdir is sort of like a chroot. I also tried --admindir and --root in various combinations to see if I could use the dpkg system relative to / but install relocate the files but they didn't work. I guess rpm has a relocate option that works but not Ubuntu.
You can also write a script that runs dpkg-deb with a different environment for 6 times, generating 6 different packages. When you make a modification, you simply have to run your script, and all 6 packages gets generated and you can install them on your machines avoiding postinst hacking!
Why not install to a standard location, and simply use a postinst script to create symbolic links to the desired location? This is much cleaner, and shouldn't break anything in dpk -I.