Unix FIFO in go? - unix

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.

Related

clearmake doesn't like my MAKEFLAGS=j12 values

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.

how to get Disk Space used/free/total in Common Lisp

Seems that there is no standard functions to get used/free/total of Disk space in Common Lisp.
There is statvfs.h in Linux/Mac and GetDiskFreeSpaceEx function in Windows for C/C++.
Personally, it would call an executable to do that using a library.
Calling df -h with IOLib for example.
But this is not portable (particularly IOLib, but there are other libraries), and you have to parse the output of the commands.
That's one reason I love programs which have "machine readable" outputs: you can glue them up programmatically (à la shell script).
Another way would be to actually call these c function, using cffi or uffi (ffi standing for foreign function interface), but I haven't used neither, so I can't say much about it.
Oh, search on quickdocs.org, there is probably a library exactly for that, or maybe just to access the OS's API.
I wrote a new project cl-diskspace using statvfs to get disk total/free/available space in Common Lisp. Support Mac/Linux/Windows.
Update: 2015-07-11 now support Windows! Thanks to pjb, Guthur, Fare, |3b|
Install cl-diskspace with QuickLisp:
$ git clone https://github.com/muyinliu/cl-diskspace.git
$ cp -r cl-diskspace ~/quicklisp/local-projects/
Load cl-diskspace with QuickLisp:
(ql:quickload 'cl-diskspace)
Usage of cl-diskspace:
Get disk space information
(diskspace:disk-space "/")
Will get something like this:
127175917568
16509661184
16247517184
Means that the total space is 118.44G, free space is 15.38G and available space is 15.13G
Get disk total space
(diskspace:disk-total-space "/")
Will get something like this:
127175917568
Get disk free space
(diskspace:disk-free-space "/")
Will get something like this:
16509661184
Get disk available space
(diskspace:disk-available-space "/")
Will get something like this:
16247517184

Turbo Pascal BGI Error: Graphics not initialized (use InitGraph)

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

any way to get rxvt to recognize shift+tab?

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.

How to distinguish Xsun from Xorg, programmatically?

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.

Resources