I am new in Linux and don't know much about it's installation manner. It's interesting for me to know where does it install the pockesphinx program?
where is continuous.cfile?
How Linux can find and execute this command: pocketsphinx_continuous -inmic yes ?
Where stuff is installed depends on how it was installed. Usually: If you were using your package manager, refer to your distrobutions documentation. If you extracted a tarball or installed using a script from a projects website, refer to their documentation.
If you are able to invoke the program from your terminal from everywhere, it will probably reside somewhere on your $PATH. You can show which directories are included in your path by issuing cat $PATH in your terminal of choice.
Also, the locate command is useful if you need to locate a file on your disk. I.e. locate pocketsphinx would give you all files that has the pocketsphinx string in its name, and its location. If you just installed the program, you might need to run a sudo updatedb to rebuild the index.
Related
I have some Unix Executable Files in a paticular directory, say /Users/myUserName/Developer/sdcc/bin/.
I find I must get into this directory using cd before running that command, or it complains zsh: command not found.
But it can be of inconvenience. I know the commands can be used in any directory if it's installed by Homebrew. How can I do the same thing?
Homebrew usually links the necessary executables to /usr/local/bin directory, which should be in your $PATH. Thus, when you execute a command like sdcc, your shell will seek through the $PATH directories, and when it looks at /usr/local/bin, it will find sdcc, follow the link and execute it.
Some packages do not perform this linking, which means you cannot execute them without knowing where they are. You can ask Homebrew to tell you where a package is installed: brew --prefix <formula>, where <formula> is the package name (e.g. brew --prefix sdcc). The executable files will normally be under a bin subdirectory. For example, brew --prefix sdcc would likely tell you something like /usr/local/opt/sdcc; then you can invoke sdcc using /usr/local/opt/sdcc/bin/sdcc, without having to cd there. You could also put /usr/local/opt/sdcc/bin into your $PATH directly, though I do not recommend it. Another alternative is to create your own bin (mine is in $HOME/.local/bin), put it in $PATH, and link there (ln -s <source> $HOME/.local/bin/) any executables you wish your shell to easily find.
However, with Homebrew packages, I strongly suggest you do not try to imitate Homebrew by yourself, by installing things in Homebrew's domain. You can confuse Homebrew and create problems. Instead, let Homebrew do it.
If you need to install a package on a different OS than the one you are downloading at, you may need to first find out the bottle tag for the target (installation) computer. For example, for Big Sur, it is big_sur. See brew info --json <formula>, under bottle.stable.files you should find the bottle tags. Use --bottle-tag <tag> in step 1 and 2 to select the right OS.
Use brew fetch --deps <formula> to download (but not install) a package, including its dependencies. If you use the --verbose flag, Homebrew will tell you where it downloaded each of the files.
If you haven't used --verbose and still want to know where the downloaded files are: brew deps <formula> will list all the packages it depends on. If a package needs to be compiled, you may need to also use the --include-build option. brew --cache <formula> will show you where a package file is downloaded.
If you need to copy a package file to another computer, you should find out where the Homebrew would expect to find it: use brew --cache --force-bottle <formula> on the target computer, and copy the package file there. Don't forget to do that for each dependency package as well.
After that, brew install <formula> will install from cache.
The only part of this process that needs internet connection is the first step, brew fetch.
For Unix (which MacOS is a family member) and Unix-like (eg. Linux) operating systems the thing that controls this feature is the PATH environment variable.
To know which folders allow you to run programs without cd-ing into them or prefix ./ to your program name you can print out the value of PATH:
echo $PATH
On my machine it prints out:
/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin:/Users/slebetman/bin:/opt/homebrew/bin
There are two things to notice:
The string is a list of folder paths separated by :
There is a path listed as /opt/homebrew. Presumably this is where homebrew installs command-line programs.
Copying your program/script into any of the folders listed in PATH will allow you to use it like any installed/built-in command. This is what it means to install command-line programs on Unix. It's that simple.
There is another thing to notice: I have in my PATH the folder /Users/slebetman/bin. This is my own personal standard - probably not invented by me but one I adopted from my college days - for installing my own programs. I have this ~/bin folder on all my Unix and Linux machines. It is where I keep my personal collection of scripts that I've written or collected over a lifetime.
Having a personal ~/bin folder is nice because you don't need sudo permission to write to it. Also, if you buy a new PC/Mac you can just copy the folder to your new machine and all the scripts you've gotten used to now exist on the new machine. Better yet, you can manage the folder with git and sync it with github/gitlab/bitbucket to make it easy to keep all your computers updated.
Since PATH is a standard environment variable you can easily modify it to add your own folder. Just add the following in your .profile or .zshrc or .bashrc file (depending on your shell) to add your own bin folder to PATH:
export PATH=$PATH:$HOME/bin
The command above simply says add $HOME/bin to PATH and export it so that other programs will inherit the new PATH variable.
In your case you can even do something like:
export PATH=$PATH:/path/to/your/sdcc/bin
to have all your SDCC commands work like regular commands.
I use v0.6, but certain packages do not function with v0.6 (such as Interact.jl). How can I install v0.5? I am running Ubuntu 16.04.
First we have to download the latest Julia version from https://julialang.org/downloads/
I used the “Generic Linux Binaries for x86” version. The choice between x86 and ARM depends on the processor of your machine. Also choose between 32 bit and 64 bit versions based on the operating system and processor you have on your machine.
After download, you will get a compressed tar.gz archive having name similar to “julia-0.6.2-linux-x86_64.tar.gz”. As the “julia-0.6.2-linux-x86_64.tar.gz” name suggests that I downloaded the Julia version 0.6.2 which is latest at the time of writing this.
The names may differ. Adapt the names accordingly.
Remember these are binaries, these don't need to be installed as they can be directly used from the directory they are extracted.
I am assuming that the downloaded file is in your ~/Downloads directory of Ubuntu.
Open the terminal and navigate to the directory where the downloaded tar.gz file is stored, in present case the Downloads directory.
The terminal when just opened will show:
x#xpc:~$
where x should be replaced by your username and xpc should be replaced by your computer name.
Navigate to the Downloads directory using cd Downloads and then press Enter to get following terminal:
x#xpc:~/Downloads $
Extract the tar.gz file using the command
tar -zxvf julia-0.6.2-linux-x86_64.tar.gz
Now a directory with extracted contents will be generated in the same parent directory as of the compressed archive with a name similar to julia-xxxxxxxxxx where xxxxxxxxxx may be a combination of alphabets and numerals.
This is the final directory you need to run the latest Julia version, no installation is needed.
To run Julia, you can directly run using the julia file in location julia-xxxxxxxxxx/bin/julia as discussed below.
Navigate to the bin directory in the extracted directory using
cd /Downloads/julia-xxxxxxxxxx/bin
The terminal will now be like:
x#xpc:~/Downloads/julia-xxxxxxxxxx/bin $
Now run the command ./julia to run julia on the terminal as shown below.
The terminal will now change to julia as presented below. I know the representation is little different here as this is all I can manage to copy from the terminal to present it to you.
julia>
But the problem is that I have to navigate to the directory every time to run Julia.
Many people have discussed on the internet about defining the path and alias through very complex procedures and as I am not a hardcore computer geek, it was really difficult for me to understand.
I came to know about making a soft link.
So I decided to make a soft link to the Julia to run it directly from anywhere with a short command without navigating to the directory containing it.
I always try to do things neatly, so I decided to keep the extracted directory named julia-xxxxxxxxxx in the /opt directory of my system as most of my important programs reside in that.
You need root permissions to copy a file into the /opt directory, so I used the command sudo su and then provided password to get the super user privileges:
x#xpc:~$ sudo su
[sudo] password for x:
root#xpc:/home/x#
Now navigate to the directory presently containing the extracted directory:
root#xpc:/home/x# cd /Downloads/
root#xpc:/home/x/Downloads#
Copy the directory using:
root#xpc:/home/x/Downloads# cp -r julia-xxxxxxxxxx /opt
After the directory is copied to the destination, now we will make the soft link in a directory which is in the system path so that the soft-link can be called from any location to run Julia.
To find out the directories in the system PATH use echo $PATH, you will get a list of paths of directories separated by colon(:) such as /usr/local/bin. You can use any of them. I used /usr/local/bin for the soft link.
Navigate to the chosen folder.
root#xpc:/home/x# cd /usr/local/bin
The terminal will become
root#xpc:/home/x/usr/local/bin#
Create the soft link using
root#xpc:/home/x/usr/local/bin# sudo ln -s /opt/julia-xxxxxxxxxx/bin/julia julia
Now return to the normal user terminal using the keyboard combination Ctrl+D at the empty terminal root#xpc:/home/x/usr/local/bin#.
The terminal prompt will become:
x#xpc:~$
Type the newly made soft link i.e. julia in the terminal as shown below
x#xpc:~$ julia
This is where the magic happens and you get this:
julia>
The instructions can be used for any version of Julia in Ubuntu.
Source
Firstly, you should really read the post that Reza Afzalan linked. It gives you everything you need to know about how to install. If you prefer a list:
Go to the Julia download page.
Download the Generic Linux Binary for your OS (probably 64-bit for Ubuntu 16).
Install it.
Find where the installed Julia binary executables are stored on your machine.
Symlink Julia v0.5 and Julia v0.6 to different aliases, e.g. julia5 and julia6. You can store the symlinks in a directory like /usr/local/bin.
Open julia5.
Start downloading your packages with Pkg.add.
It's very easy, here's how to install it on Linux in 8 steps:
1- go to Julia downloads page
2- Choose you version (32bit or 64bit) from Generic Linux Binaries, and then download it.
3- extract .tar.gz file in home or any place you would like to install Julia on it.
4- run > gksudo gedit /etc/environment on your terminal to setup envirnment path.
5- edit file :/Path_To_extracted_File/bin in my case it was like this:
":/home/okasha/julia-d386e40c17/bin"
6- Save edits and close the file.
7- Restart your machine.
8- Open your terminal again and run > julia -version
you shoud get "julia version 0.6.2" for Example according to your installed julia version.
Run > julia to open julia session.
Reference
Just type this
sudo apt install julia
I'm using cygwin installed on Windows 10 and trying to access awscli from it.
I used pip install awscli to install awscli. This installed awscli. I then tried to run only aws to see if it is installed and I get the following error:
-bash: /cygdrive/c/Program Files/Anaconda2/Scripts/aws: C:\Program: bad interpreter: No such file or directory
I'm not sure why this is happening. Any help in this regard would be highly apreciated.
This is still an issue even with the latest version of AWS cli. So after some trial and error I found a pretty good workaround that will not make you switch your favorite shell.
First, make sure python is on your PATH. That is from anywhere in the system you can just run python and it work.
Find the aws script and open it for editing (for me it was located in c:\Program Files\Python36\Scripts\aws) and change the hashbang (that would be the first line in the script) to #!python.exe. For me it was set to #!c:\Program Files\Python36\python.exe. That space in the middle of Program Files caused the issue when that path got converted to Linux like path. Changing it to #!python.exe sidesteps the issue.
When you update AWS cli, repeat the workaround.
PS. You could also avoid this issue by installing python somewhere in a folder without spaces in path. That requires to reconfigure your system, so I did not do that myself.
I would install the standard python and ensure it is coming up first in your path with which python and which pip. Path issues like this are due to mixing and matching executables targeting different platforms in my experience. Certain commands do not implement functionality to convert paths from Windows to Linux and back (it appears your specific commands are failing on spaces).
Since you say you are on Windows 10, if you have the anniversary edition, I would recommend Windows Subsystem for Linux over cygwin. You will likely see less Windows issues on WSL since it uses the exact same ubuntu packages you would use on Linux instead of the cygwin port and maps them low level to the NT Kernel.
The Problem comes from "Program Files" having a space. This is something that is related to cygwin (I encountered the same error with git bash on windows). In a script I had something like this:
#!/c/Program Files/some_program/executable.exe
Escaping the space with a backslash or using quotes didn't work.
The solution is to use the DOS' short filename:
Progra~1 for "Program Files"
Progra~2 for "Program Files (x86)"
So my line would turn into:
#!/c/Progra~1/some_program/executable.exe
In Windows:
cd .. to go to home directory which shows pwd as /.
Now, cd to /cygdrive/c/Program\ Files/Anaconda2/Scripts
Now, run: python aws configure
Example:
user#user /cygdrive/c/Program Files/Anaconda2/Scripts
$python aws configure
When i want to use ghost4j on OS X 10.9, i see this error:
Unable to load library 'gs': dlopen(libgs.dylib, 9): image not found
I have installed ghostscript library on my macbook using this site.
how can i fix this problem. I can not install ghostscript using port and brew for some reason.
First you need to find the file libgs.dylib which was installed by the installer package compile the libgs.dylib library from source, and make a note of where you installed it to.
Hopefully it should have been installed to a standard library location, and there should be nothing more you need to do. If not, you need to set the environment variable DYLD_LIBRARY_PATH. In a terminal this would be done by typing export DYLD_LIBRARY_PATH=$DYLD_LIBRARY_PATH:/directory, replacing /directory with the full path of the actual directory containing libgs.dylib. After typing this, in that terminal, if you run your application, it should work. To make it take effect permanently you would need to add the export command to your ~/.bash_profile. Or to make it take effect for all user accounts on your computer, you could add it to your /etc/profile.
If this doesn't work, I suppose the Ghostscript library could be 32-bit - you would need a 64-bit library I think.
A bit of an old thread but maybe useful for people still looking for an answer.
Install ghostscript using port
port install ghostscript
That done, you need to create a link so ghost4j finds the dylib.
cd /usr/lib
sudo ln -s /opt/local/lib/libgs.9.10.dylib libgs.dylib
Once I did that it worked like a charm.
As part of a long, sordid story whose end goal is simply to get GMP installed for use with code::blocks in Windows, I am trying to configure gmp. I do this with the following command:
./configure --prefix=${gmp_install}
Everything starts out well enough. After a few minutes and a bit of progress, everything grinds to a halt and I get this message:
configure: error: No usable M4 in $PATH or /usr5bin
I don't even know what M4 is, but I discover that it is some sort of macro processor. So I download it, and add the folder to my Path variable. Then I start the configure again, but same result.
Is there something that I need to do to M4 to get it working? I'm truly at a loss. Thanks for your help.
If you're using debian based OS, do sudo apt-get install m4. If internet isn't there or you have just the package of m4, copy it in /opt, configure it and later on change the $PATH value to the one you have now.
If you are using cygwin, the setup installer has a working package of m4. Then there's no need to download m4 or change $PATH.
I came up with your same problem, I solved it by running the Mingw package installer, and search for msys-m4 in the list, select all and then Apply Changes, it should let you ./configure just fine :)
Assuming you are on MSYS2 (You seem to have a sh), you can install m4 via pacman -S m4.
Be careful that if you run configure through a shell, that you don't pick WSL's bash accidentally (which is in %System32%/bash.exe). Which is what happened in our build system...