I'm running OS X 10.10.5. I'm getting an error trying to open a terminal:
tput: unknown terminal "xterm-256color"
This is obviously a missing termcap entry.
$ port list ncurses
ncurses #6.0 devel/ncurses
Any ideas how to install 'ncurses-term' on OS X?
$ sudo port install ncurses-term
Password:
Error: Port ncurses-term not found
The problem was with an Anaconda package:
https://groups.google.com/a/continuum.io/forum/#!topic/anaconda/XKMFYqM12Vg
It appears there is some problem with an earlier version of the ncurses package that interferes with terminfo
conda install -c r ncurses
Notwithstanding the existence of bloated/monolithic packages on Linux, the package maintainers for ncurses packages often split up the 7Mb of terminfo into "base" and "term" chunks (and separate it from the library). The MacPorts maintainer for ncurses has not done this. The terminal database is part of the "ncurses" package. For instance, I see this from
port contents ncurses#6.0_0+universal
under /opt:
/opt/local/share/terminfo/73/screen.xterm-256color
Also there is a system (non-port) copy here:
/usr/share/terminfo/78/xterm-256color
Applications linked with ncurses will generally use one or the other, depending on whether they are linked with the port- or system-library. However, ncurses can be told to look some other place by setting the TERMINFO variable. If you happen to have copied some customization from another machine into your .bashrc, that could have set TERMINFO.
By itself, tput gives no clue where it is looking for a terminal entry. You can check the output from env to see if TERMINFO is set. The infocmp utility can show where it looks (since late 2011), using the -D option, e.g.,
$ infocmp -D
/usr/local/ncurses/share/terminfo
/usr/share/terminfo
/opt/local/share/terminfo
By the way, OSX does not (barring some specialized ports) use termcap as such. It uses terminfo, as part of some given release of ncurses (see for example the manual page for tgetent).
Related
I hope that I'm tagging/asking on the correct page. I'm Using Linux Mint 6.0, but it could be OS independent.
So the used command for installing Firefox was
nix-env -iA nixpkgs.firefox-esr
When I type which firefox, I get:
/home/foo/.nix-profile/bin/firefox
So Linux Mint comes with Chrome preinstalled, which has a launcher, e.g. also in the start menu. How do I get that for firefox as well? I didn't find a tool to create such a launcher in Mint and I actually think, that nix should do that for me.
EDIT: I also found this page which seemed helpful and advertised e.g. the KDE Kickoff, but I wasn't able to get that one to run.
I can only speak for Ubuntu launchers, but other distros will have launcher files that will have a similar setup
TLDR, add ~/.nix-profile/share to XDG_DATA_DIRS env variable on login. Add the following to ~/.profile after nix loading commands
export XDG_DATA_DIRS=$HOME/.nix-profile/share:$XDG_DATA_DIRS
Explanation:
Installed packages via nix will have an immutable path in nix/store. ~/.nix-profile/bin/firefox is the derivation your current nix environment is linked to (if you update the firefox package, it'll point to the new one)
This means you can create a launcher file for that executable. Lets see if the firefox-esr derivation comes with a desktop launcher or not:
$ nix-build '<nixpkgs>' -A firefox-esr
This will build the package and give you a derivation path. For my current channel it is /nix/store/3iipcmiykgr4p34fg3rkicdz1bw584gm-firefox-102.2.0esr
If I check inside it, there is a .desktop file which defines Ubuntu launchers:
$ ls /nix/store/3iipcmiykgr4p34fg3rkicdz1bw584gm-firefox-102.2.0esr/share/applications
firefox.desktop
These files will also be available under ~/.nix-profile/share/applications so you can simply add that to XDG_DATA_DIRS env variable before boot
If an application did not have one, you can manually make one and add it under ~/.local/share/applications, then set the executable path to the nix one
So SuperSandro2000 explained in the comments, that firefox from nix ships with a .desktop file already. This can be easily added to the start menu and lies in
/nix/store/...-firefox-XXX.X/share/applications/firefox.desktop
If there is no such file included, the most direct way could be (imho) to just create a simple bash script:
#!/bin/bash
./home/foo/.nix-profile/bin/firefox & #Run Firefox
echo Firefox was started with PID $!
In order to make it runnable, enter chmod +x your_skript_name.sh. Afterwards, ./firefox 2> /dev/null & can be used instead to run it silently in the background.
You can also consider the developer/command line options for firefox (Archive) or this blog article here.
Maybe /usr/bin/menulibre is also the right application, it allows you to create .desktop files. This app can also be found by right-clicking on the start "menu".
My code runs fine with the command
gfortran-11 Hello.f90 -o Hello
but if I check the version of the gfortran, it shows 9.3.0 on Ubuntu 20.04.
So my concern is how to make it default or do I have to type gfortran-11 every time I use it?
One way to solve this is to create a symlink to gfortran-11 called gfortran, and to add this symlink to your PATH with higher priority than the original gfortran.
This could be acheived by e.g. running
mkdir ~/.bin
ln -s [path_to_gfortran-11] ~/.bin/gfortran
and then adding
export PATH=~/.bin:$PATH
to your .bashrc or equivalent.
This is really a system administration question. Since it tangentially deals with a compiler, it might be on-topic.
There are various ways how concurrent versions are treated in various operating systems. If you use Linux, you can use
alias gfortran=gfortran-11
You can put this into your ~/.bashrc or some equivalent, if you use one (e.g., the ~/.bash_aliases file - see https://askubuntu.com/questions/1414/how-to-create-a-permanent-alias).
For tools like Make you can normally set
export FC=gfortran-11
or
FC=gfortran-11 ./make
or some other variable name that your Makefile happens to use. I use this routinely with SCons.
Another good option is the update-alternatives system. See https://askubuntu.com/questions/26498/how-to-choose-the-default-gcc-and-g-version
If you configure (install) the appropriate options according to the instructions (change g++ to gfortran), you will be able to switch between the versions using
sudo update-alternatives --config gfortran
I use Pycharm to create and manage my virtualenvs in my projects.
The problem is that after adding a library with pycharm, when I type the command (pip3 freeze --user), the library does not appear in the command result.
I have to manually type the pip install command each time so that the library is visible.
What manipulation should I do in PyCharm to solve this problem?
For what you are saying, the first thing that comes to mind is that you should use:
pip freeze
And not
pip3 freeze
Because the command mapped to the pip version when you have virtualenv activated is the first. Note that for installing you seem to use pip, and not pip3
Moreover, the --user option afaik is related to the packages installed in the user folder:
--user Install to the Python user install directory for your platform. Typically
~/.local/, or %APPDATA%\Python on
Windows. (See the Python documentation for site.USER_BASE for full details.)
If your packages are installed in the virtualenv folder, I would tell you to not use that option.
Also please make sure you have your virtualenv activated. In linux you can do so by source path/to/virtualenv/activate
Edit
I understand that the reason you are using pip3 is because you may have different versions of Python in your machine. Let me explain you a bit further how it works, because version management is usually a headache for many programmers and it is common to find problems when doing so.
If you install different versions of Python in your linux machine, and you do that as root, then the installation will proceed for the whole system. Usually Python2 installation folder for Linux machines is /usr/bin/python. However, I am uncertain of which directory is used for Python3 installations. You can check that easily by doing whereis python3. You can serach the path to binary of any command by doing whereis command. Note that this works also for whereis python as far as you don't have virtualenv activated.
Aditionally, the link to the binary of a command (or the set of instructions to be exectued, more broadly) is defined in certain folders in Linux, depending on whether you created the command as root or as a user, and possibly also on the distro. This works differently in Windows, that uses the Registry Edit utility to handle command mappings. When you enable your virtualenv, what you are doing is creating an environment that enables mapping system commands such as python to the Python installation in your virtualenv folder.
When you disable the virtualenv, the command points again to the default installation path. Same happens with pip, so incorrect usage of this tool may result in different packages being installed in different locations, and therefore not appearing available for the right Python version at any given circumstance.
In Linux, environment variables are shell dependent, though you can write them out with echo $variable and set them with variable=value (from bash). The search path is simply called PATH and you can get yours by typing echo $PATH.
Source: https://askubuntu.com/a/262073/426469
I encourage you to check other questions in SE network such as this: https://unix.stackexchange.com/a/42211/96121, to learn more about this.
Addendum
Quick tip: it is common to use the pip freeze command as follows:
pip freeze > requirements.txt
It is a standard that leads to understanding that modules in such file are required for the correct functioning of your application. That lets you easily exclude the virtualenv folder when you install the program in another computer, since you can readily know the requriments for a fresh installation. However, you can use the command as you want.
(Note: this is similar to this question, but the answer there does not apply.)
Running under FreeBSD, I have ncurses installed via the usual pkg method for FreeBSD, but because I've seen some odd behaviour with a previously working curses program, I decided to download an ncurses source tarball from the official site and compile it under my home directory.
The compile went fine, but attempting to run any of the included test programs results in:
Error opening terminal: xterm.
The documentation does say:
NOTE: You must have installed the terminfo database, or set the
environment variable $TERMINFO to point to a SVr4-compatible terminfo
database before running the test programs. Not all vendors' terminfo
databases are SVr4-compatible, but most seem to be.
So it looks like the answer is to set TERMINFO, but to what? I don't see any terminfo database under the build directory itself, but I do have a file /usr/local/share/misc/terminfo.db installed as a result of the regular FreeBSD installation.
Nevertheless, setting (csh syntax) setenv TERMINFO /usr/local/share/misc/terminfo.db (or the same omitting the .db extension) doesn't make any difference.
(Note: this shouldn't matter because I haven't so far attempted to install the local build, but when I ran "configure", I used: ./configure --prefix=$HOME so that it would install under my home directory.
By default, ncurses uses (reads/writes) a directory-tree of terminal descriptions. Optionally (and seen in the makefile for the ncurses port), it reads/writes a hashed database file, as well as reads the directory-tree.
The INSTALL file in the ncurses sources goes into some detail about the --with-hashed-db configure option, which you apparently overlooked. The term(5) manual page gives a better overview.
While there is no shortage of information on how to set a text editor for the Subversion Command Line Interface to use (see here, here, and here for example), I can't figure out where my local system is getting the text editor information from.
On my system, when I perform an svn commit, it opens vim for a commit message. Since this is what I want, I never really thought about it. This has always just worked. However, recently a co-worker was trying to commit, and it failed with an error saying the editor was not set. I never went out of my way to set an editor, so I am very confused about this.
I am running Ubuntu 12.04 and I have compiled and installed the Subversion CLI client version 1.8.10 from source code. Previous to that, I was using whatever Ubuntu's Canonical system installed with apt-get install subversion.
The Using External Editors section of the Subversion Book states the following possibilities for setting the text editor:
--editor-cmd command-line option
SVN_EDITOR environment variable
editor-cmd runtime configuration option
VISUAL environment variable
EDITOR environment variable
Possibly, a fallback value built into the Subversion libraries (not present in the official builds)
I have investigated these places and have not found how the default text editor is set on my computer:
Not using --editor-cmd option when committing
SVN_EDITOR environment variable not set
editor-cmd is not set in either my ~/.subversion/config, nor in /etc/subversion/config. Both of these files exist, but the line is commented out.
VISUAL environment variable not set
EDITOR environment variable not set
I'm downloading the official repository, so there should be no fallback.
There must be another place where the default can be set. Does anybody know?
Edit: There was a suggestion that Subversion might be calling /usr/bin/editor, and this is not set up on my co-worker's machine. I discovered that /usr/bin/editor is set up the same on both my system and my co-worker's system.
When you download the source directly (and build it - assuming you have the build dependencies met) you specify (or you can omit it) the default fallback editor. Normally source builds are done with something like this on Ubuntu (assume I have extracted/downloaded the subversion 1.8.10 source from here):
./configure
make
sudo make install
Notice the ./configure command above doesn't specify any options. The defaults will install to the prefix /usr/local . Prior to issuing those commands (on Ubuntu 12.04) I ran sudo apt-get build-dep subversion . I then did the commands above to build and install. I made sure that options 1-5 (In the OPs question) were not satisfied and then tried to commit a change to a repository. I got this as a response:
svn: E205007: Commit failed (details follow):
svn: E205007: Could not use external editor to fetch log message; consider setting the $SVN_EDITOR environment variable or using the --message (-m) or --file (-F) options
svn: E205007: None of the environment variables SVN_EDITOR, VISUAL or EDITOR are set, and no 'editor-cmd' run-time configuration option was found
Since I didn't remove the official Ubuntu subversion I had to run mine as /usr/local/bin/svn to make sure I was using the one I built. I could have used sudo apt-get remove subversion to remove the official one as well just to make sure.
Now if one runs these commands to rebuild the source:
make clean
./configure --with-editor=/usr/bin/editor
make
sudo make install
One should find that if options 1 to 5 are not satisfied and this version of subversion is run it should default to running whatever /usr/bin/editor points to. On Ubuntu that will depend on what alternative is being used.
So when Ubuntu does an official build where does their fallback editor come from? I went to the 12.04 source repository for subversion at this link . On the right hand side I downloaded the diff file subversion_1.6.17dfsg-3ubuntu3.4.diff.gz . I opened up the diff file Ubuntu uses and scrolling down you can find they use this set of ./configure options (flags):
confflags := \
--prefix=/usr \
--libdir=$(libdir) \
--mandir=\$${prefix}/share/man \
--with-apr=/usr \
--with-apr-util=/usr \
--with-neon=/usr \
--with-serf=/usr \
--with-berkeley-db=:::db \
--with-sasl=/usr \
--with-editor=/usr/bin/editor \
--with-ruby-sitedir=/usr/lib/ruby \
--with-swig=/usr \
--with-kwallet \
--with-gnome-keyring
The bold entry shows that they use /usr/bin/editor as their fallback.
I have built subversion 1.8.10 from source on Ubuntu 12.04 and got the expected behavior. This suggests one of these possibilities:
On one of the systems the options 1 through 5 is actually met.
One version of subversion was built with the --with-editor configure flag (either directly or indirectly). The fallback would point to whatever the --with-editor configure flag was set to.
On one of the systems the wrong version of subversion is being run. One possibility is that the official subversion on Ubuntu is in fact being used. If that is the case it was built to use /usr/bin/editor as a fallback.
On one of your systems you have an alias (or equivalent) for svn that specifies an editor. Aliases would be specified in a startup script like ~/.bashrc, ~/.bash_profile, /etc/bash.bashrc for example.
I think the normal way to specify this on Linux and other Unix-like systems, is to set the VISUAL environment variable (for GUI editors) or the EDITOR variable (for editors running in a terminal).
Try this:
update-alternatives --display editor
Run strings on your svn binary to see if it mentions Vim or any related env vars inside.
Also committing under strace -f may reveal something.
Set this in your .bashrc file.
Don't forget to "source .bashrc" or reopen terminal.
export SVN_EDITOR='vim'