Our application runs some commands in a headless mode using frame buffer display. We can't rely on fact that Xvfb is installed on every machine, but we suppose that X server is, so we bundle Xvfb binary into our application. The problem is that on some machines, when running bundled Xvfb we get the following fatal error:
could not open default font 'fixed'
Is there a way to bundle basic fonts as well, and point Xvfb binary to them, or is there a more elegant solution to this?
Thanks!
There is a more elegant solution coming up in the future, it is called Xdummy and is the ability to use a real X11 server with the dummy driver to get a virtual screen backed by a real server (Xvfb is barely maintained nowadays). More details (and packages) here, it is based on Xdummy by Karl Runge but is much cleaner (no shared library tricks)
This will be part of Xorg server 1.12 (due shortly)
Until then, you could wrap Xvfb in a little script which figures out where the fonts are on the system (there aren't that many places) and adds the -fp string default font path argument to the command line.
Modern versions of libXfont from X.Org have the basic "fixed" and "cursor" fonts builtin, but until the more recent versions (I believe Xorg 1.7 from 2009), you needed to specify "built-ins" in the font path explicitly for Xservers like Xvfb to find them.
Related
I'm coding a Rust app and since it's fairly small and there don't appear to be any stable UI frameworks, I've made it run in the console using println! and whatnot for input/output. However since this program is intended to be used by people directly after downloading from the internet (due to its use case), they're likely to just double click on it instead of navigating to their downloads directory in a terminal and running it from there.
This is a problem because on Linux, it runs in the background waiting for input and looks like it's not working. On Windows, Rust programs do open in CMD by default. (and in fact many of the search results for my question were about disabling this behavior - the exact opposite of what I want!).
So is it possible to somehow make my application open in the system's default terminal? My preferred way would be to somehow embed in the executable to open in terminal (similar to the -mconsole compiler flag on MinGW). Otherwise would it be possible to detect it's in the background and fork it into a terminal? If that's not possible then is it at least possible to detect that the app is not running in a terminal and throw up a message box telling the user to run in a terminal?
My app is cross-platform but I'm OK with writing code conditionally compiled on one OS.
One typical way would be to distribute a program.sh along with your executable. If .sh extension is bound to opening a terminal in their window manager of choice, it would open automatically. If not - it is enough of a hint for running it from the shell.
Without this file you could:
Detect if the program is already running inside a terminal can be done with isatty(). There's a crate for it.
If not, spawn the terminal app process (see process::Command) and relaunch the program with it by passing its path to the terminal command line options. As #Caesar mentioned there's a bunch of popular terminals that you might want to check for presence on Linux. If nothing is found, xterm could sometimes be a fallback.
I've had a break from programming the last two years and want to start up again. Right now I'm using a Windows computer, but my work and compiler is on my Linux computer.
My question is:
Is it possible to move my entire emacs work environment from Ubuntu to Windows 10? I did some changes in emacs back in the days that I got used to and would love to continue like that on my Windows computer.
Briefly...
The most important things to copy are your ~/.emacs.d directory and your init file (see C-hig (emacs)Init File for the different filenames this might have, or check with C-hv user-init-file).
See C-hig (emacs)Windows HOME regarding where the .emacs.d directory should live on your Windows system.
Note the comments in that Info node on the site-lisp directory as well, in case you've been using elisp libraries in there (possibly without realising), as they can form part of your Emacs configuration as well.
Any byte-compiled elisp (.elc files) should remain compatible so long as you're moving to an equal-or-newer version of Emacs (which sounds likely in this case). Natuarally things do change between releases, though, and it's possible to encounter incompatibilities when upgrading, but I wouldn't worry about that in advance -- try the latest version first, and if you run into problems that you can't solve (which shouldn't be very likely), you can always install the version of Emacs you were originally using.
I have a problem where I need to know the filesystem path of the current binary, as well as those of any loading (as opposed to loaded) binaries. Here is an example (for Windows): Say we have an executable A.exe, which dynamically binds to B.dll, which in turn binds to C.dll. How could code executing in C.dll get the file paths of C.dll, B.dll, and A.exe?
Oh, and I need to be able to do it on Linux, Mac, and Windows.
On Linux, the closest thing I've found is dl_iterate_phdr, but the who-loaded-who info is missing.
On Windows, The Dynamic-Link functions don't have quite the right functionality.
On Mac, all I can find is what's in dlfcn.h, which is rather pithy for this purpose.
Thanks.
This is a very specific issue but, based on what I've seen online, a surprisingly common one. I'm on a rather old version of Scientific Linux 5, which is based on Red Hat. I use vim with the Solarized vim color scheme, and my TERM environment variable is usually set to xterm-256color. This worked fine until I started using tmux. On non-empty lines in vim, the color scheme only extended to the end of the document's characters, the remaining whitespace being plain back background.
The stock fix for this in online guides is to set TERM='screen-256color'. However, upon doing this I would get the ominous warning: WARNING: terminal is not fully functional - (press RETURN), when trying to do innocuous things like read man pages. However, everything seemed to be working fine, and the Solarized bug was fixed.
I've found a functional fix - using TERM='xterm-256color' by default and adding this line to my .bashrc:
alias v='function _vim(){ TERM='screen-256color'; vim $1; TERM='xterm-256color'; };_vim'
but it seems like a hack. Anecdotally, I've also set alias tmux='tmux -2', which is a common suggestion with color-scheme-related issues.
I also know that the terminfo screen-256color is available on my machine.
So, really, the main befuddling thing is that, when using TERM='screen-256color', I'm getting those warnings about full functionality when nothing seems to be wrong.
I don't have root access, so ideally any fix suggestions wouldn't need that.
EDIT: I should mention that TERM='screen-256color-bce' gave the same problems as TERM='screen-256color'.
The user's environment is not specified, but likely using bash and less (Scientific Linux 5 does not have more).
The package list on Scientific Linux 5's ftp site, shows ncurses-5.5-24.20060715.src.rpm, which does not include screen-256color (it was added to ncurses in October 2006). That system might have the later terminal database by some post-install change.
An application using termcap would not see this terminal description. Scientific Linux's bash and less programs could have used termcap rather than terminfo. A quick check of the changelog for bash-3.2-21.el5 says
* Fri Feb 1 2008 Miroslav Lichvar <mlichvar#redhat.com> - 3.2-21
- Link with libtermcap
On some systems, a missing termcap entry will cause a warning. But with Scientific Linux 5, the given warning message comes from less, which checks its terminal description (using the termcap interface), to ensure that it can clear the remainder of the current line, the remainder of the screen and the entire screen.
In Scientific Linux 5, the less package is built with ncurses. A problem with less using TERM=screen-256color would be one of these possibilities
the screen-256color entry is not really installed, or
there is some problem with the termcap interface provided by ncurses.
While there were ongoing performance-fixes for the screen program around this time, the former seems the more likely, as seen in this discussion of a poorly-written entry for screen-256color in early 2006: Re: screen-256color terminfo entry?. What I get from reading this is that there was some poorly-written terminal description (not part of ncurses) which produced the problem. By the time it was proposed for inclusion in ncurses (October 2006), the problem had been repaired. In any case, it would have been corrected at that point.
I followed the steps from skia site for compiling skia r1236 on my Ubuntu 12.04 64 bit machine.
When i run the tests , no window comes up to show the graphical result.The output on console is :
[1/33] PDFPrimitives...
...................
[33/33] BitmapCopy...
Finished 33 tests, 0 failures.
If i put a Bitmap to a file using SkImageEncoder::EncodeFile , i do get graphical output on the file. This confirms that the library is working fine but is not able to invoke linux window system.
Another problem is that while running text , i get following error
SkFontHost::OpenStream failed opening 1
--- no context for glyph 0
I have installed all freetype libraries as described by the Skia website , but still have error whichever path i use in SK_FONT_FILE_PREFIX.
My "/usr/share/fonts/" folder have
cmap
truetype
type1
X11
I noticed there is a file SkOSWIndow_Unix.cpp but nobody seems to be calling it from the test code.So my question is
1) How do we get the output to be shown on a window?
2) WHat should be the value of SK_FONT_FILE_PREFIX?
PS : The Windows port worked fine
Skia r1236 is at least two years old; you should be using something newer. The directions on the website are less than a year old.
The Linux tests and the Windows tests produce the same thing. You should see the same result from Linux as you did from Windows.
Part of the question is which particular tests you are running. From your description of the Linux shell output, these were the "gm" tests, which do not display windows. They draw pictures onto off-screen canvases.
With the "-w " option, gm will write the images as pngs into a directory.
With the "-r " option, gm will read images from a directory and compare them to the images it generates.
The SampleApp application in Skia does use the Linux window system. However, we do not support the "views" library that was used to create it. Skia is a platform-independent rendering engine; you'll need to provide your own windows management.
Note that gm functions a bit differently since somtime in the 6000s or 7000s; a default checkout will no longer contain the reference images for all GMs on all platforms.