Let's take an example. When I run:
xkbprint $DISPLAY keyboard.ps
what happens in the system? I would like to know how the X really work because I regularly get nasty error reports such as
Fatal Error: Cannot load geometry for /tmp/launch-NawGIk/:0
Exiting
I know that the X11 was designed in a way that it is easy to extend. But how? How does the X11 protocol work? How do the X extensions work?
Whatever happens, I'm pretty certain it isn't going to be what you expect.
The syntax of xkbprint(1) is
$ xkbprint sourcefile destfile
and sourcefile should be a compiled xkb file. $DISPLAY is going to resolve to something like mymachine:0.0, which isn't a very reasonable file name.
Actually, since you're running a Mac, it's echoing exactly what it's seeing: /tmp/launch-NawGIk/:0 is the special OS/X magic to let launchd run X apps. The error message means that it's not finding a geometry or display in that file. Which is no surprise since there is no file named `/tmp/launch-NawGIk/:0
Try reading the man page, and see if you don't have more luck with a compiled .xkm file.
More generally, if you want a starting introduction to X, try this article.
Man xkbprint says:
The xkbprint comman generates a
printable or encapsulated PostScript
description of the XKB keyboard
description specified by source. The
source can be any compiled keymap
(.xkm) file that includes a geometry
description or an X display
specification.
As Charlie Martin pointed out, xkbprint is misusing your $DISPLAY as a file name. Try specifying the display more precisely, to avoid ambiguity with file name. Try man xhost. Maybe passing simple ":0" will fix the problem?
Related
I've been trying to change GNUCash UI language as it's described here: Link
...by running the following command in the terminal:
LANGUAGE=ar_SY LANG=ar_SY gnucash
But it returned the following:
The locale defined in the environment isn't supported. Falling back to
the 'C' (US English) locale
Any solution please?
I think there must be a general way to run a GTK application with a specific language.
tl;dr:
$ LANGUAGE=nl_NL.UTF-8 LANG=nl_NL.UTF-8 LC_ALL=nl_NL.UTF-8 gnucash
(change into the locale codes of your choice)
I know I'm a bit late to the game, but I was also running into issues with languages.
As an extra, I really want to keep my system locale at en_C.UTF-8 / C because the Dutch language prescribes a comma for decimal separator and completely messes with day-to-day programming tasks (especially in LibreOffice). So I need GnuCash to run in 'translation mode'.
Anyway, running
$ LANGUAGE=nl_NL.UTF-8 LANG=nl_NL.UTF-8 gnucash
did not work for me either (just runs in English). Then, I found this link (accessed on Aug 19, 2015) about locale settings in GnuCash.
In the section 'OS dependend tweaking', at the end of the 'Changing the Language on Linux' sub-section, they hinted to also specify the LC_ALL environment variable:
If you can get the graphical interface in the correct language , but you can't get the accounts in the desired locale, you have to add the LC_ALL variable, like in the following example:
LANG=it_IT.UTF-8 LANGUAGE=it_IT.UTF8 LC_ALL=it_IT.UTF-8 gnucash
This does the trick for me:
$ LANGUAGE=nl_NL.UTF-8 LANG=nl_NL.UTF-8 LC_ALL=nl_NL.UTF-8 gnucash
Perhaps this might work for you:
$ LANGUAGE=ar_SY LANG=ar_SY LC_ALL=ar_SY gnucash
There might be a problem in the .po translation files. In that file, the direction should be defined according to this article.
If anybody is interested, a solution that can be used on Mac OS X (Yosemite) is to add these lines in Gnucash (in this case for Italian):
export LANG=it_IT.UTF-8
export LANGUAGE=it_IT.UTF-8
export LC_ALL=it_IT.UTF-8
Following the advice on the above metioned link, these three lines should be added just above this part:
$EXEC "$bundle_contents/MacOS/$name-bin" $* $EXTRA_ARGS
Gnucash is an executable file located inside Gnucash.app that is present in your Applications folder (you should see Gnucash without .app extension). If you select it and in the dropdown menu you click on "Show Package Contents", you will find the Gnucash executable file in /Contents/MacOS folder. You can then modify the file with your preferred text editor.
I am trying to debug an application that is cross-compiled on a Windows host for a Linux target.
The problem:
Because the initial compilation is in windows the stored source file paths in the binary is of the form C:\Users\foo\project\.... On the Linux target I have put the source files under \home\foo\project\.... By default gdb does not find the source file because of the different path.
What I have tried so far:
Use "directory" command in gdb to give an exact path for the .c source file in the target Linux system where the app is being debugged. This works but unfortunately there are literally hundreds of files so this solution is unrealistic.
Use the set substitute-path C:\\Users\\foo\\project /home/foo/project command to have gdb substitute all prefixes. Note that the \\ seems necessary such that show substitute-path registers the right string. This unfortunately does not work. My guess is that the substitute-path command does not handle ms-dos style paths.
Tried separating the debug info out into a separate .debug file (see How to generate gcc debug symbol outside the build target?) and then using debugedit to change the paths with the command debugedit --base-dir=C:\Users\foo --dest-dir=/home/foo project.debug. Unfortunately this does not work either. debugedit seems to work fine if the existing path is all UNIX/Linux like but doesn't seem to work with ms-dos style paths.
I have looked around stackoverflow and while there are similar topics I can't find anything that will help me. Would really appreciate any suggestions/help. I realize that cross compiling from Windows is a very roundabout way but can't avoid that for the moment.
Thanks
Although it's rather old question, I did encountered the same problem. I managed to resolve it but using sed on binary executable... (yeah, a 'bit' hack-ish, but did not found another way). With sed I've managed to replace symbols paths right inside the executable, the trick is that new path's length should be the same as the old one.
sed -i "s#C:/srcpath#/srcpath/.#g" ./executable
Be sure to make new path the same length, otherwise the executable will brake.
I also have this same problem. Your option 1 isn't as bad as you think because you can script creating all the 'directory' commands with something like this python code:
def get_directory_paths():
return_array = list()
unix_path = os.path.join('my','unix','path')
for root, dirs, files in os.walk(unix_path):
for dir in dirs:
full_unix_path = os.path.join(root,dir)
escaped_unix_path = re.sub("\s", "\\\\ ", full_unix_path)
return_array.insert(0, "directory " + escaped_unix_path)
return '\n'.join(return_array)
The downside is that if you have two source files with the same name in different directories, I don't think gcc can pick the right one. That worries me, but in my particular situation, I think I'm safe.
For option 2 (which I suspect would fix the aliasing condition from #1), I think the problem is that the substitutions are not ending with a "file separator" according to the linux so they aren't applied:
To avoid unexpected substitution results, a rule is applied only if the from part of the directory name ends at a directory separator. For instance, a rule substituting /usr/source into /mnt/cross will be applied to /usr/source/foo-1.0 but not to /usr/sourceware/foo-2.0. And because the substitution is applied only at the beginning of the directory name, this rule will not be applied to /root/usr/source/baz.c either." (from https://sourceware.org/gdb/current/onlinedocs/gdb/Source-Path.html#index-set-substitute_002dpath )
I haven't tried anything like your #3 and I also considered something like #dragn suggestion, but in my situation the paths are not even close to the same length, so that will be an issue.
I think I'm stuck with #1 and a script, but if anyone has other suggestions, I'm interested options :-)
Does anyone know if there is a reader (text-to-speech) tool for cygwin or linux? I know of Microsoft's narrator, which partially works by sounding out what I type in the cygwin window (bash command line) but it doesn't report anything written to stdout.
Is there a native Cygwin tool anyone knows of?
BRLTTY, which is available through Cygwin's setup.exe, apparently does have some speech support in addition to being able to drive Braille displays. I've got no experience with it though.
BRLTTY seems to be just an interface for Braile displays - I couldn't make it "talk".
Instead get festival binary from bottom of here, put it in C:/festival, and in cygwin
echo "hello world" | /cygdrive/c/festival/bin/festival.exe --tts
should say hello world. Then I put it into a script say.sh and calling
~/say.sh hi
actually does what you'd expect :)
How can you set a string to be used instead of standard input? For example, when running the latex command in Unix it will always find some trivial errors, to skip through all errors you have to enter "r" into the command line (I now know that with latex specifically you can use -interactionmode nonstopmode, but is there a more general solution to do this?)
Is there anyway to specify that this should be done automatically? I tried redirecting standard input to read from a file containing "r\n", but this didn't work.
How can I achieve this?
Not all applications that need input can be satisfied with their stdin redirected.
This is because the app can call the isatty C function (if written in C, or some equivalent call for other languages) to determine if the input come from a tty or not.
In such situation, there is a valuable tool to use, and this is expect.
latex --interaction=MODE
where MODE is one of:
errorstopmode: stop at every error and ask for input
scrollmode: scroll over non-fatal errors, but stop at fatal errors (such as "file not found")
nonstopmode: scroll over non-fatal errors, abort at fatal errors
batchmode: like nonstopmode, but don't show messaes at the terminal
For interactive use, errorstopmode (the default) is fine, for non-interactive use, nonstopmode and batchmode are better.
But beware, there are no trivial errors: all errors must be fixed, and all warnings should be fixed if possible.
Redirecting stdin works without problems here:
/tmp $ tex '\undefined\end' <<< r
This is TeX, Version 3.1415926 (TeX Live 2010)
! Undefined control sequence.
<*> \undefined
\end
? OK, entering \nonstopmode...
(see the transcript file for additional information)
No pages of output.
Transcript written on texput.log.
You've got two plausible answers detailing the way to handle Latex specifically. One comment indicates that you need a more general answer.
Most usually, the tool recommended for the general solution is 'expect'. It arranges for the command to have a pseudo-tty connected for input and output, and the command interacts with the pseudo-tty just as it would your real terminal. You tell 'expect' to send certain strings and expect certain other strings, with conditional code and regular expressions to help you do so.
Expect is built using Tcl/Tk. There are alternative implementations for other languages; Perl has an Expect module, for example.
From the man page:
-interaction mode
Sets the interaction mode. The mode can be either batchmode, nonstopmode, scrollmode, and errorstopmode. The meaning of these modes is the same as that of the corresponding \commands.
Looks like -interaction nonstopmode might help you.
It is a simple question to which I am not able to find the answer:
Given a LaTeX command, how do I find out what package(s) it belongs to or comes from?
For example, given the \qquad horizontal spacing command, what package does it come from? Especially troublesome since it works without including any package!
Given a LaTeX command, how do I find out what package(s) it belongs to or comes from?
Consult your references:
If it's in the index to the TeXbook, it's inherited from TeX, the engine that drives LaTeX.
Otherwise, if it's in the index to the LaTeX manual, it's probably defined in latex.ltx or in one of the standard class files, not in a package.
Otherwise, if it's in the index to The LaTeX Companion, the page number probably tells you what package it's from.
Otherwise, you could do some fancy grepping on the results of find /usr/share/texmf -name '*.sty', but be prepared for a painful exercise.
Or, you could ask on http://stackoverflow.com. But then some idiot will respond by asking why you want to know...
You can search http://www.ctan.org/tex-archive/info/symbols/comprehensive/ for that information and more.
Remember that LaTeX is a macro language on top of TeX, and all the macros are made up of TeX which doesn't need to be imported. \qquad is in that category.
As far as I know, there is no really good general answer to this. But there are a number of techniques you might try for any given command. In the case of \qquad, it's part of basic TeX. Remember that you can always use TeX in interactive mode:
$ tex '\show\qquad'
This is TeX, Version 3.141592 (Web2C 7.5.6)
> \qquad=macro:
->\hskip 2em\relax .
\show\qquad
? x
No pages of output.
Some macros are added by LaTeX on top of TeX, such as \begin:
$ tex '\show\begin'
This is TeX, Version 3.141592 (Web2C 7.5.6)
> \begin=undefined.
\show\begin
? x
No pages of output.
whereas
$ latex '\show\begin'
This is pdfTeXk, Version 3.141592-1.40.3 (Web2C 7.5.6)
%&-line parsing enabled.
entering extended mode
LaTeX2e
Babel and hyphenation patterns for english, usenglishmax, dumylang, noh
yphenation, greek, monogreek, ancientgreek, ibycus, pinyin, loaded.
> \begin=macro:
#1->\#ifundefined {#1}{\def \reserved#a {\#latex#error {Environment #1 undefine
d}\#eha }}{\def \reserved#a {\def \#currenvir {#1}\edef \#currenvline {\on#line
}\csname #1\endcsname }}\#ignorefalse \begingroup \#endpefalse \reserved#a .
\show\begin
? x
No pages of output.
Everything else comes from packages. If you really wanna know which package a macro comes from (other than by google or grepping your texmf tree), you can check after each package you load whether it's defined. Try defining this before any \usepackage commands:
\let\oldusepackage\usepackage
\renewcommand\usepackage[1]{
\oldusepackage{#1}
\ifcsname includegraphics\endcsname
\message{^^Jincludegraphics is defined in #1^^J}
\let\usepackage\oldusepackage
\fi}
Then when you run latex on your .tex file, look for a line in the output that says includegraphics is defined in graphicx. It's not likely, but some devious packages might do bad things with \usepackage so there's a chance this might not work. Another alternative would be to simply define the command you're interested in before loading any packages:
\newcommand\includegraphics{}
Then you might get an error message when the package that defines the command is loading. This is actually less reliable than the former approach, since many packages use \def and \let to define their macros rather than \newcommand, bypassing the "already-defined" check. You could also just insert a check by hand in between each load: \ifcsname includegraphics\endcsname\message{^^Jdefined after graphicx^^J}\fi
Due to lack of reputation I cannot comment on Steve's answer, which was very helpful to me, but I would like to extend it a bit.
First, in his second approach (fiddling with usepackage) the case where usepackage has optional arguments is not dealt with. Secondly, packages are often loaded by other packages via RequirePackage which makes it hard to find the actual place of definition of a command. So my refinement of Steve's answer is:
\usepackage{xargs}
\let\oldusepackage\usepackage
\let\oldRequirePackage\RequirePackage
\renewcommandx{\usepackage}[3][1,3]{
\oldusepackage[#1]{#2}[#3]
\ifcsname includegraphics\endcsname
\message{^^Jincludegraphics is defined in #2^^J}
\let\usepackage\oldusepackage
\let\RequirePackage\oldRequirePackage
\fi}
\renewcommandx{\RequirePackage}[3][1,3]{
\oldRequirePackage[#1]{#2}[#3]
\ifcsname includegraphics\endcsname
\message{^^Jincludegraphics is defined in #2^^J}
\let\usepackage\oldusepackage
\let\RequirePackage\oldRequirePackage
\fi}
The xargs package is used here to get the unusual options of usepackage right (first and third parameter are optional).
Putting this directly after documentclass should tell where includegraphics is defined.