I was trying to follow the instructions here to get drush installed on cygwin:
https://www.drupal.org/node/1432756#comment-11184267
However, running "drush" from my drupal project's folder did nothing (it didn't tell me -bash: this_command_I_made_up: command not found as it does for a command that doesn't exist).
Eventually I tried to run the symlink command like this:
ln -s /usr/local/src/drush/drush.bat /usr/bin/drush.bat
instead of this:
ln -s /usr/local/src/drush/drush.bat /usr/bin/drush
In other words, I added the .bat suffix to the filename path (drush.bat) instead of leaving it as plain old drush. Now I get results as I expect when running drush commands from my drupal project folders, but I have to type in drush.bat instead of drush when running drush commands.
I was just wondering if anyone could shed some light on the situation as to why the plain old drush symlink without the .bat suffix doesn't work. Thanks!
You may need to make the src/drush/drush.bat executable. If the symlink you make has a .bat extension (or .exe, etc.), it will automatically be executable in cygwin.
For files without extensions, the file must be marked executable.
For symlinks without extensions, the source (src/drush/drush.bat) must be marked executable.
To mark a file executable, use the command chmod +x src/drush/drush.bat.
Related
I made a change in a shell script to use a version of cmake and can't find this script. I want to use cmake-3.18.5, I have installed it and changed the path to it in bashrc, but it still uses the older version cmake-3.18.2. How to find where this happens?
You're problem appears to be that you put the filename in your path, not the directory.
First, try this at the command line to make sure cmake is installed:
/HOME/cmake-3.18.5/bin/cmake --version
Then if that works, change your path on the command line:
export PATH=/HOME/cmake-3.18.5/bin:$PATH
Note that PATH takes directories, not files or executables.
Now type
type -aP cmake
Make sure the right directory shows up (/HOME/cmake-3.18.5/bin/cmake)
Now put this path command in your .bashrc file and see if it works this time.
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 "$#"
Created a simple debian/ubuntu package with some library files (*.so).
Works fine except, it installs them as default in the root path "/".
Since I've recreated my Makefile to output to $DESTDIR/ instead of "the usual" directory that I provide in the Makefile, when compiling from source, how do I now set the path of where the files should be installed now? I know there are several choices when using dh_make to create the package, "s" being the default one. Still, can't seem to find anything on where to tell dpkg to put the installed files.
Secondly, a Deb Library package containing only ".so" files should still be a "Single binary" since I gather that using the Library is for development purposes? Since this is a library, I just wanna make sure that's not the cause of the files being installed in the wrong location. What I mean is .so files and header files installation?
What I've used:
dh_make -e my#email.com -f ../myfile-1.0.tar.gz
dpkg-buildpackage -rfakeroot
and some configurations set i debian/control, $DESTDIR in Makefile.
Seems that it was fairly simple, yet very confusing. This works, not sure if there is a better solution.
In my makefile I have a few variables
InstallTo = /usr/lib
install:
mkdir -p $(DESTDIR)$(InstallTo)
cp $FILE_TO_COPY $(DESTDIR)$(InstallTo)
This way it will create the directory tree inside the *.deb file. I had some trouble using /usr/local/lib instead of /usr/lib/ and rmdir complained when trying to delete it and it had no files (just directories). Not sure why, but changed it to /usr/lib instead.
Since someone voted this up, I'm guessing someone were also looking for the answer and this is my solution. Perhaps someone can provide a better one if there is one.
Just a note, $DESTDIR variable is the variable that dh_make suggest the user to use in our Makefile. It's the path to where dpkg will build the program and where it will install it so it can be included in the .deb file.
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 am a windows developer switching over to OSX. I am very confused though. I am learning node.js and the documentation tells me to add a reference to nodemon at the path...
/usr/local/bin/nodemon
However when I am at the terminal and I type 'ls' I get the following output...
And that doesn't have a /usr/ folder ... And what is even more confusing is that if I do...
ls -a
Then I can see all my hidden folder with a folder in called .npm which seems to have all my modules. In windows this is easy it just installs all npm modules into %AppData%/npm or something but I just don't get it on OSX can somebody enlighten me please?
ls lists the directories and files in your current working directory.
You can find your current working directory with pwd (short for 'print working directory')
You can change your current working directory with the cd (change directory) command. In your case, you could run
cd /usr/local
ls
and it would show you the bin directory. Alternatively, you could directly run
ls /usr/local
As a special extra note, the Terminal Prompt itself actually displays the current working directory (by default). In your case, it shows ~, which is shorthand for the user profile directory, which the Terminal opens to automatically. It is generally /Users/<username>.