Buildroot: Ncurses includes tput? - ncurses

I have a startup sh script that plays an "animation" of text, using tput to manipulate / delete lines on the terminal. Unfortunately it does not seem that tput is present on my system, I have included the ncurses library, which apparently also contains tput.
I am looking for either a way to get tput OR an alternative.
Thanks

You forgot to enable BR2_PACKAGE_NCURSES_TARGET_PROGS.

You have to check ncurses programs when setup buildroot config
make menuconfig
Target packages -> Libraries -> Text and terminal handling -> ncurses -> ncurses programs
save
make clean (or rm -rf output/build/ncurses-6.1/)
make
After compile finish, you can find tput at output/target/usr/bin/tput
my buildroot version: buildroot-2021.02.3

Related

How do you get a launcher for firefox?

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".

Making gfortran version 11 as default

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

tput: unknown terminal "xterm-256color"

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).

How do I build a gvim executable

I have successfully built vim on linux (centOS). However, the ./configure, make, make install trilogy didn't build a gvim executable. Yet, I can start the gui version with vim -g. I seem to remember that when I built vim (and gvim) in other occasions, that also the executable gvim was built. So, is there a flag that I can pass to ./configure so that the executable gvim is also built. Or am I missing something completely different?
If you can start the GUI with vim -g or with :gui then you already have your executable. Perhaps something went wrong during make install: gvim (in /usr/bin/ or wherever) should be a link to vim.
Also, the standard instructions for compiling vim are a little different from the usual ./configure; make; make install since vim has a make rule to run configure. From vim74/src/INSTALL:
2. Unix
=======
Summary:
1. make run configure, compile and link
2. make install installation in /usr/local
I remember a discussion a while ago on the vim mailing list about changing this to be more standard, but I do not think that is going to happen.
I use this settings to build vim
./configure \
--prefix=/path \
--enable-pythoninterp \
--enable-cscope \
--enable-fontset \
--with-x \
--with-features=huge
but it's just an example, you should always experiment with the settings to find the one that fits your case, the autocompletition feature on the bash helps with the configure script too, so it's easy to find new flags that way.

configure.ac not finding dependencies under cygwin

I'm using an autoconf/automake configure script on cygwin, and I have the problem that it doesn't fin my dependencies.
For example I do, in my configure.ac:
AC_CHECK_LIB(mp3lame,lame_init,,AC_MSG_ERROR(Required library LAME not found.))
AC_CHECK_HEADER(lame/lame.h,,AC_MSG_ERROR(Headers for LAME not found.))
To find lame. Lame is installed, if I do locate lame.h I find it in /usr/local/include/lame/lame.h. Now, if I set LIBRARY_PATH and INCLUDE_PATH with
export INCLUDE_PATH=/usr/local/include/
export LIBRARY_PATH=/usr/local/lib/
It works as expected. I have installed lame by downloading it and running:
./configure
make
make install
So I would think that it should end up in a "standard enough" path for my configure script to find it. In a similar way, I'm checking for the json parser jansson using:
PKG_CHECK_MODULES(JANSSON,jansson)
And it doesn't find it unless I do:
export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig/
Is this a problem with cygwin (I wouldn't think so) or a problem with my configure.ac script?
This is not a problem with cygwin, nor with your configure.ac. It is a "feature" of PKG_CHECK_MODULES and is one of the reasons I recommend against using it. If a configure script generated from a configure.ac that uses PKG_CHECK_MODULES is used, it is necessary that the user set PKG_CONFIG_PATH. The best approach is to use AC_CHECK_LIB instead of PKG_CHECK_MODULES. You are absolutely correct that ./configure && make && make install gives you a standard installation that should work. The problem is that PKG_CHECK_MODULES does not play well with standard installations.

Resources