I just downloaded Erlang using apt-get onto Ubuntu 10.10. How do I run the examples that come with Erlang (the examples you can get through apt-get install erlang-examples). I tried going to the directory where they were stored and compiling ball.erl, but I got this error:
ball.bea#: error writing file
error
The directory where those examples are stored isn't writeable by normal users. To compile a .erl file, the compiler needs to be able to write out the compiled .beam file.
One way around this is to copy the files to a directory you can write to and compile them there:
$ mkdir erlex
$ cd erlex
$ cp /usr/lib/erlang/lib/gs-1.5.11/examples/src/* .
$ erlc *.erl
You need the erlang-dev package installed for that to work.
You can run the ball example like so:
$ erl -s ball
ball here is the module name, and the Erlang emulator defaults to calling the start/0 function in that module, which is correct in this case.
You don't actually have to compile these examples, however. The Ubuntu erlang-examples package ships with them already compiled:
$ cd /usr/lib/erlang/lib/gs-1.5.11/examples/ebin
$ erl -s ball
After closing the GUI window in each, say q(). to get out of the emulator. This may seem weird to you until you realize that everything about Erlang is designed with long uptimes in mind. The mere fact that the last process the emulator was running has stopped isn't enough reason for the BEAM emulator to shut itself down. Something else might be started in that same emulator later, after all.
Related
I'm new to data science and wanted to do a little tutorial, which requires airflow, among other things. I installed it on windows using git bash in VS Code. I tried running it but it had a problem not being able to load the sqlite3 import
command (module not found error). I figured out that if I added the directory of sqlite3.py to the path, it would run, but now it gives me a similar error: pwd module not found from daemon.py
File "C:\ProgramData\Anaconda3\lib\site-packages\daemon\daemon.py", line 18, in <module>
import pwd
ModuleNotFoundError: No module named 'pwd'
Strange to me that it can't find pwd. Obviously pwd works in both git bash and powershell natively. It seems like a basic universal command. I'd love to learn more about what's going on. I don't want to have to end up adding 100 things to path just to get this program to run. I'd love any insights anyone can provide.
PS I'm using Anaconda.
it's seems to be the side effects of Spawning new Python Daemons .
You likely can fix this by downgrading the Python-Daemon :
pip install python-daemon==2.1.2
At some point, whenever I use vi from the command line (windows 10/WSL) it starts up in insert mode, meaning that everything I usually do to navigate ends up adding stuff to the file, wasting time having to clean it up.
I didn't have a vimrc file, and there doesn't seem to be anything in my bash rc files to modify vi behavior. Any ideas what I may have done or any ideas how to stop this behavior? I'm using Ubuntu-20.04
FWIW, adding a .vimrc file with tab related settings didn't change it's behavior. I looked at the /etc/vimrc file, and nothing inside it seemed relevant.
After plowing through google search and trying everything I understand about configuring 'vim' and doing comparison tests, I think:
This behavior is specific to Windows Terminal when opening a WSL terminal. Using WSL's "native" terminal (i.e., clicking the "Ubuntu 20.04 LTS" menu in the "Start" menu) doesn't have this problem.
My original motivation for switching to Windows Terminal is for its multi-tab feature. But this new behavior is crazy -- it works against years of my muscle memory of using "vi", and I'm almost certain that one day I'll accidentally update some configuration file while reading it in "vi". And, I cannot re-train a new muscle memory because all the rest of the UNIX world (e.g., when I SSH into a remote server) hasn't changed. This is like constantly switching between a Mac keyboard and a PC keyboard where the Ctrl key, etc., are in different places.
My solution: I switched to MobaXterm. It has multi-tab support, and is actually richer in features compared to Windows Terminal.
Please run the following:
alias | grep vim
sudo find / -name .vimrc 2>/dev/null
These commands should show you all the places to check, change the alias or fix the .vimrc files found.
Do you find it always going into edit mode, when you vim a file directly and when you use vim as the git commit editor for example?
EDIT:
You could also try which -a vim or whereis vim to see if you have multiple versions. Or failing that sudo find / -name vim 2>/dev/null
here is a better solution. I downloaded the binary.
https://github.com/lxhillwind/vim-bin/releases/tag/v9.0.0978
Put the vim command in /usr/bin/vi
Put the runtime in:
/usr/local/share/vim/runtim
sudo apt remove vim vim-common vim-runtime vim-tiny
sudo apt purge vim vim-common vim-doc vim-runtime vim-tiny
The second line actually gets rid of residual-defaults.
There is also a defaults.vim someplace on the system. I just nuked it.
I went through and made sure there were no aliases or vi or vim configuration files, but still no luck.
This is a horrible solution, but the only thing that is keeping my sanity right now.
vi -c ":imap jj "
You can alias it in your .bashrc. Looking into better solutions.
OS: Debian 8.1 X64
trying to install eJabberd Community server based on this tutorial
At the end of installation, it pops error message
Error: Error running Post Install Script.
The installation may have not completed correctly
What am I doing wrong?
It looks like /bin/sh is Dash on your system (apparently the default since Debian Squeeze). However, the postinstall.sh script inside the package uses brace expansion, which while widely supported in various shells is not required by the POSIX standard, and thus Dash is not in error by not supporting it. The postinstall.sh script should either specify /bin/bash instead of /bin/sh in its first line, or abstain from using Bash-specific features.
You should be able to get a functioning ejabberd install by explicitly running the postinstall script with Bash:
sudo bash /opt/ejabberd-15.07/bin/postinstall.sh
Is there a recommended way to "bootstrap" an Erlang distribution? I would like to run erlang on the bunch of machines where I do not have root elevation nor development tool-set (no compilers etc ...) . My thinking was to pre-package (on the machine with the same architecture) as much as I can before. What are the minimal requirements for an usable Erlang environment?
You can use the different erlware tools. Using the latest Sinan, you can even create a standalone release with the erts bundled.
Ok, I should have read it before ... (from INSTALL.md)
* Install using the `release` target. Instead of doing `make install` you
can create the installation in whatever directory you like using the
`release` target and run the `Install` script yourself. `RELEASE_ROOT`
is used for specifying the directory where the installation should be
created. This is what by default ends up under `/usr/local/lib/erlang`
if you do the install using `make install`. All installation paths
provided in the `configure` phase are ignored, as well as `DESTDIR`,
and `INSTALL_PREFIX`. If you want links from a specific `bin` directory
to the installation you have to set those up yourself. An example where
Erlang/OTP should be located at `/home/me/OTP`:
$ ./configure
$ make
$ make RELEASE_ROOT=/home/me/OTP release
$ cd /home/me/OTP
$ ./Install -minimal /home/me/OTP
$ mkdir -p /home/me/bin
$ cd /home/me/bin
$ ln -s /home/me/OTP/bin/erl erl
$ ln -s /home/me/OTP/bin/erlc erlc
$ ln -s /home/me/OTP/bin/escript escript
You can look at Wing3D for example.
CouchDB is another example. (Credit to tbikeev.)
While trying to install a build server I've run into a funny problem where all cygwin commands can be run from a DOS box but sometimes do not work when called from make. What's even more weird is some make targets, like 'clean', work and others, like 'all', do not.
Here's a representative makefile extract. The quoting has hosed the formatting but tabs are where they should be, trust me:
.PHONY: all
all: update_autoconstants
/usr/bin/rm -f $(OBJ_DIR)/myfile1.txt
rm -f $(OBJ_DIR)/myfile2.txt
.PHONY: clean
clean:
rm -f $(OBJ_DIR)/*.*
Notice that in 'all' one rm call has a full path and one has no path. Also notice that clean's rm call has no path.
To this the response to a 'make -C makefile all' is:
/usr/bin/rm -f ../../obj/myfile1.txt
rm -f ../../obj/myfile2.txt
make: rm: Command not found
make: *** [all] Error 127
ie. the full path works, the no-path does not. What then starts my head spinning is the 'clean' target in make with no path works fine. it's not just cygwin commands, make can't find the compiler either. It seems pretty clear that somewhere the path has been hosed, although the environment variable PATH is set, but only in make - this works fine from a DOS prompt.
C:\>cygpath --unix c:\programme\cygwin\bin\rm
/usr/bin/rm
The machine is running Windows Server 2003 German language in a virtual machine on VMWare ESX, the cygwin install was done yesterday, installed in c:\programme\cygwin\ and everything else is clean vanilla Windows installation.
Any ideas? Thanks in advance.
Not really so much of a solution as a workaround - we made all the makefiles use absolute paths to the exe files they need which is in any case a bit nicer than searching a path and taking what you find.
To perhaps save someone some Googling commands in cygwin's bin directory can best be called:
CYGWIN_EXE_PATH = /usr/bin
RM = $(CYGWIN_EXE_PATH)/rm.exe
.PHONY: clean
clean:
$(RM) -f $(OBJ_DIR)/*.*
And similarly files in the program files directory like this:
COMPILER_DIR = "$(PROGRAMFILES)/TASKING/c563 v3.6r1"
Hope that helps.
I've had the exact same thing.
rm not being found by make from within a makefile.
My workaround was to run the makefile from within bash. Previously I was just running make from a windows cmd box. This cured the problem for me, but created new issues. The permissions of some files that were created during the make had very odd permissions being set.