I put this in my .ackrc:
--type-set=DUMB=*.orig
--noDUMB
... but I'm still seeing files like main.py.orig in my ack results. I tried doing --type-set=DUMB=*.*.orig too, but that didn't work either.
More info
Run from my command line (OSX Snow Leopard with :
timmfin at lorien in ~/dev/performable/rafa on landing-pages-csv-and-more!
± ack modules --python | grep '.orig'
src/rafa/main.py.orig:25:import rafa.ui.modules.helpers
src/rafa/main.py.orig:26:from rafa.ui.modules.performable_form import PerformableForm
src/rafa/main.py.orig:27:from rafa.ui.modules.page_form import PageEditForm
src/rafa/main.py.orig:28:from rafa.ui.modules.settings_form import SettingsForm
....
timmfin at lorien in ~/dev/performable/rafa on landing-pages-csv-and-more!
± cat ~/.ackrc
--color
--sort-files
--smart-case
--type-set=sass=.sass
--type-set=coffee=.coffee
--ignore-dir=rafa/static
--ignore-dir=compiled
--ignore-dir=compressed
--ignore-dir=venv
--ignore-dir=build
timmfin at lorien in ~/dev/performable/rafa on landing-pages-csv-and-more!
± ack --version
ack 1.94
Running under Perl 5.10.0 at /usr/bin/perl
Now that ack 2.0 is available:
--ignore-file=ext:orig
, either on command line or .ackrc.
It is possible to ignore files by name. To ignore ctags generated files:
--ignore-file=is:tags
Filters for different uses can be found on documentation.
For ack version 1.x
I found this worked if I removed the asterisk (from the Ackmate wiki)
--type-set=DUMB=.orig
--noDUMB
You can see what types of file ackmate supports by running (including those you've specified in ~/.ackrc):
~/Library/Application\ Support/TextMate/PlugIns/AckMate.tmplugin/Contents/Resources/ackmate_ack --help type
For ack version 1.x use the following. In my case, I want to ignore .css files. I have to set the type called SOMETHING. Then set it to --noSOMETHING to remove it from search.
ack --type-set=SOMETHING=.css --noSOMETHING "My Bitcoin."
ack doesn't recognize .orig files in the first place. I'm guessing you are somehow invoking ack -a either from your ackrc or ACK_OPTIONS.
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.
For running GNAT metric (for Windows, GPL 2017 or CE 2018) I'd like to include the RTL sources as well. There is a "-a" switch but it seems to be ineffective. When I'm forcing visibility of RTL sources, only ada.ads and system.ads are processed. Guessing it is a "crunched name" issue (RTL file names forced to 8 character names) I've tried other tricks without success.
My question is: is there a way to get the RTL source metrics (of the source files actually used) with GNAT Metric?
I'm using the command
gnatmetric -a -xs -nt -j0 -Pmyproj.gpr -U somemain.adb
TIA
In the meantime I've found a workaround by using the gnathtml.pl script.
I've customized the script a bit by removing the H1 headers.
The result is a few hundreds of HTML files with the sources of units actually used: the script does find all dependencies, recursively, through the .ali files - including the RTL.
Then I group the HTML files together, convert them back to text files, pass them through Adalog's Normalize tool for removing comments and empty lines, count lines with the wc command, and the job is done.
We need to (re)generated third party packages on EL7 but we don't want to change SPEC file as suggested (%define debug_package %{nil} https://www.redhat.com/archives/shrike-list/2003-April/msg00069.html) and neither changing the ~/.rpmmacros file as it is on a shared box for RPM build.
Is there any way to solve this via command line (additional parameter) with rpmbuild?
After many tests I found the solution. In fact, it is possible to define debug_package outside of the SPEC file, using --define. Which gives:
rpmbuild --define "debug_package %{nil}" -ba SPECS/original.spec
Result is: I don't modify the third party SPEC file and no RPM -debuginfo is generated.
rpmbuild --rebuild --nodebuginfo file.src.rpm -- this still generates debuginfo rpms
Another solution:
cat /etc/rpm/macros
%debug_package %{nil}
How do I add a new filetype to ack, with version 2.04 (ack-2.04-single-file). I am using the following command (Is there any way to search in filetypes not recognized by ack?), but I receive an error.
$ ack --type-set=input=.i
ack-2.04-single-file: No regular expression found.
Using the following does what I wanted:
--type-add=input:ext:i
I found the answer by creating a .ackrc file with:
ack --create-ackrc
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.