VendorString() doesn't work, it's always Sun Microsystems, even if it is Xorg built for Solaris.
$ xdpyinfo | grep vendor
vendor string: The X.Org Foundation
vendor release number: 10601901
This is xorg-server 1.6.1 on Linux. Hopefully XOrg and XSun on Solaris will differ here.
To output these two fields, xdpyinfo calls the ServerVendor macro to determine the vendor, then parses the return of the VendorRelease macro differently depending on what ServerVendor was.
By the way, what's VendorString()? I don't have a function or macro by that name...
It's possibly a little hacky, but if you look at the list of extensions returned from Xsun and Xorg you should see that Xorg has a few extra XFree86-derived extensions.
xdpyinfo can be used to list the extensions via the command-line to check for differences; programmatically you can use XListExtensions() or XQueryExtension().
(I haven't got a Xsun X Server to hand but I'm pretty sure when I've looked in the past they have differed quite abit).
Thank you!
Oops, VendorRelease() string it is.
Anyway, unfortunately we cannot bet on this string. It changes often enough to have a trouble, for Xsun as well as for Xorg. I have found a solution working (hopefully) for them and for various other (derived) servers like Xvfb, Xnest etc.
Xsun does use a third value in an array of the keysyms for KP_ (numpad) keycodes. Xorg uses 1-st or 2-nd. A sniffer should first, obtain a keycode for a KP_ keysym, for instance XK_KP_7,
second, sniff what is in the XKeycodeToKeysym(d,keycode, [0-3]). Our XK_KP_7 will be on the index 2 for Xsun.
Related
I use both GNU Make and - woe is me - ClearCase' clearmake.
Now, GNU make respect a flag named MAKEFLAGS, which for me is set to j20 on this multi-core machine I'm on. Unfortunately, clearmake also recognizes this option, yet doesn't except this value. It tells me:
clearmake: Error: Bad option (j)
clearmake: Error: Bad option (2)
clearmake: Error: Bad option (0)
Questions:
Why is this happening? Should ClearMake accommodate GNU Make's usage?
How can I get around it, other then turning the flag off an on repeatedly?
It's been 15 years or so since I used clearmake, but assuming it doesn't support the GNU make-specific GNUMAKEFLAGS variable you can use:
export GNUMAKEFLAGS=-j20
and leave MAKEFLAGS unset.
The "BUILDING SOFTWARE WITH CLEARCASE" clearly states in its T"unsupported Gnu make features" that this option is indeed not supported.
–j [JOBS]
--jobs=[JOBS]
Maybe a clearmake -C -J can help (for testing): there should then be no limit to the number of parallel builds.
Are you calling GNU make from a clearmake build script? Or are you trying to create a single makefile that will support both build tools? I think the GNUMAKEFLAGS EV is safer for GNU make specific values. I would also use
CCASE_MAKEFLAGS for any makeflags that are specific to clearmake.
CCASE_CONC to set the concurrency value. While clearmake no longer passes the -J in MAKEFLAGS, it used to, and if you're using an older clearmake (somewhere in the 7's as I recall), you could upset "child" GNU make sessions since they like -J about as much as clearmake likes -j.
Finally, check the env_ccase man page for the behavior mentioned in CCASE_MAKEFLAGS_V6_OBSOLETE. If you pass MAKEFLAGS explicitly in the build script like
$(MAKE) $(MAKEFLAGS) TARGET=x
And had started clearmake like this:
clearmake -C gnu TARGET=Y
You'll actually get both TARGET macro definitions in the command line. Setting the mentioned EV (at all) avoids the "pass defined macros in MAKEFLAGS" behavior. The switch exists because some people have makefiles that DEPEND on this behavior, while others have ones BROKEN BY this behavior...
Assuming for the sake of argument that your company has a support agreement with either IBM or HCL, this is a good time to use your support channels to bring up clearmake concerns.
I'm making a Turbo Pascal 7.0 program for my class, it has to be on Graphic Mode.
A message pops up
BGI Error: Graphics not initialized (use InitGraph).
I'm already using InitGraph and graph.tpu and I specified the route as "C:\TP7\BGI".
My S.O is Windows 7 and I'm using DosBox 0.74, I already tried to paste all the files from the folder BGI into BIN.
What should I do?
Since dos doesn't have system graphic drivers, the BGI functions as such for BP7.
So in short, use a BGI suitable for your videocard. The ones supplied with BP7 are very old, there are newer, VESA ones that you could try.
Afaik 3rd party BGI needs to be registered explicitly in code though.
At first I have had this "missing Graph.tpu"- ... and later the "Use Initgraph"-issue too.
After hours trying (and reading some not politeful comments in the internet) I finally got Turbo Pascal 7 succesfully running (in Windows 10, x64). In summary I want to share "some secrets":
install the "TP(WDB)-7.3.5-Setup.msi" (comes from clever people in Vietnam)
make sure, that there's the CORRECT PATH to the "BGI"-directory in your program-code. For example:
driver := Detect;
InitGraph (driver, modus, 'c:\TPWDB\BGI');
(By the way: This is ALL, what's there to do with "Initgraph".)
make sure, that in TP7 under "Options" --> "Directories" are the CORRECT PATHS both to "C:\TPWDB\UNITS" and Your actual working dir e.g. "C:\TPWDB\myPrograms"
THAT's IT.
Annotations: The "Graph.TPU" (usually) is already in "UNITS" (together with "Graph3.tpu" by the way).
Hazzling around old driver's isn't needed even... :)
Just the correct paths... :)
Hope, that can help ...
Is there any way to create a unix FIFO with Go language? There is no Mkfifo, nor Mknod in os package, though I expected named FIFOs are largely used in posix OS's. In fact, there is a function for creating an unnamed FIFO (pipe), but no function for creating named pipes.
Am I the only one who needs them?
In order to get it to work on Linux, I simply did a
syscall.Mknod(fullPath, syscall.S_IFIFO|0666, 0)
It seemed to do the trick.
Here is a reference for the underlying mknod() call
There is a Mkfifo, but it's in the syscall-package :)
Searching through the source gives me the feeling it's not available on anything but OS X and FreeBSD though: http://www.google.com/codesearch#search&q=Mkfifo+package:http://go%5C.googlecode%5C.com
I don't have a unix machine ready to test with. You can use cgo if you like to build a C-interface package which exports it for you.
I'm simply trying to get shift+tab to be a recognized key sequence during my rxvt terminal sessions. So I can map it to usefulness such as:
bindkey "\e[Z" reverse-menu-complete
But, based on my research, I'm pretty sure the answer is no. Just want to make sure.
This is a hard limitation of rxvt? (Is there a technical reason for this limitation? Or just an unsupported feature?)
I can't get it to emit that either, although strangely enough, the rxvt source code (as shipped with Cygwin) does appear to have support for it:
case XK_Tab:
if (shft)
STRCPY(kbuf, "\033[Z");
else {
...
Anyway, rxvt development stopped eight years ago. Try its successor, rxvt-unicode, aka urxvt, where this does work. If you're on Cygwin or MSYS and you were using rxvt without an X server, which urxvt does require, try mintty.
I see console apps print colors and seen apps such as ffmpeg print text over itself instead of a new line. How do I print over an existing line? I want to display fps in my console app either at the very top or very bottom and have regular printfs go there and scroll normally.
I need this for windows, but this is meant to be cross platform, so I will eventually have a linux and mac implementation.
There is two simple possibilities which work on linux as well as windows, but only for one line:
printf("\b"); will return for one character, so you might count how many character you want to backspace and fire this in a loop, or you know that you only write n numbers and do it likeprintf("\b\b\b\b\b\b\b\b\b\b");
printf("text to be overwritten by next printf\r"); this will return the cursor to the beginning of the line, so any next printf will overwrite it. Make sure to write a string of same length or longer so you overwrite it entirely.
If you want to rewrite several lines, there is nothing so portable as ncurses, there is libs for it on practically every operating system, and you don't have to take care of the ANSI-differences.
edit: added link to ncurses wikipedia page, gives great overview and introduction, as well as link list and maybe a translation to your preferred language
Check out ncurses. It has bindings for most scripting languages.
You can use '\r' instead of '\n'.
The ASCII character number 8 (A.K.A. Ctrl-H, BS or Backspace) lets you back up one character. ASCII Character number 13 (A.K.A Ctrl-M, CR or Carriage Return) returns the cursor at the beggining of the line.
If you are working in C try putchar(8); and putchar(13);
The magic of the colors, cursor locating and bliking and so on are inside ANSI escape codes. Any text console capable of handling ANSI codes can use them just printing them out to console (i.e. by means of echo in a bash script or printf() function in C).
Unix terminals support ANSI escape sequences and Windows world used to support them back in old MS-DOS days, but the multibyte console support put an end to this. There is more information here. However there are other ways out of just ANSI sequences printing available on Windows. Moreover if you have Cygwin installed on your Windows maching ANSI codes work just as great as on any Unix terminal.
Many people mention Ncurses library that is the de-facto standard for any gui-like text based applications. What this library does is to hide all the terminal differences (Windows/Unix flavours) to represent the same information as identical as possible across all the platforms, though from my own experience I tell you this is not always true (i.e. typical text window frames change because the especial chars are not available under all character encodings). The counterpart of using ncurses is that it is a complete API and it is much harder to start out with it than simply writing out some ANSI escape sequences for simple things such as change the font color, cleaning screen or moving back the cursor to a random position.
For the sake of completeness I paste an example of use of ANSI sequence under Linux that changes the prompt to blue and shows the date:
PS1="\[\033[34m\][\$(date +%H%M)][\u#\h:\w]$ "
You can use Ncurses -
ncurses package is a subroutine library for terminal-independent screen-painting and input-event handling which presents a high level screen model to the programmer, hiding differences between terminal types and doing automatic optimization of output to change one screenfull of text into another
Depending on the platform which you are developing on there's probably a more powerful API which you could use, rather than old ASCII control codes.
e.g. If you are working on Win32 you can actually manipulate the console screen buffer directly.
A good place to start might be here
http://msdn.microsoft.com/en-us/library/ms683171(VS.85).aspx
I have been looking for similar functions/API which would allow me to access the console as something other than a stream of text for other platforms. Haven't found anything yet, but then again, I haven't been looking that hard.
Hope it helps.