I'm trying to use pcregrep as specified in the top answer to this SO question on Cygwin. My environment is Win7 64bit running Cygwin V 1.7.20(0.266/5/3).
Using cygcheck -p pcregrep I get:
Found 6 matches for pcregrep
libpcre-devel-8.37-1 - libpcre-devel: Perl Compatible Regular Expressions library development (installed binaries and support files)
libpcre-devel-8.37-2 - libpcre-devel: Perl Compatible Regular Expressions library development (installed binaries and support files)
pcre-debuginfo-8.37-1 - pcre-debuginfo: Debug info for pcre (installed binaries and support files)
pcre-debuginfo-8.37-2 - pcre-debuginfo: Debug info for pcre (installed binaries and support files)
pcre-8.37-1 - pcre: Perl Compatible Regular Expressions utilities (installed binaries and support files)
pcre-8.37-2 - pcre: Perl Compatible Regular Expressions utilities (installed binaries and support files)
I've tried using the instructions for installing pcregrep found in this tutorial, but patch doesn't seem to be part of the cygwin install. This tutorial was found through these two SO questions along the same lines as mine:
SO Question 1 and SO Question 2, citing them so they show up in the related questions section. This man page shows that it can exist in cygwin, but trying to run the man page for it results in:
$ man pcregrep
No manual entry for pcregrep
It appears that the libraries for pcregrep exist in my cygwin install, but I don't know how to compile / extract / enable them to gain access to the utility. When I try to run it, I get the standard command not found response from bash:
$ pcregrep
-bash: pcregrep: command not found
So my question is: What do I do in cygwin to allow me to use pcregrep?
I'm not sure how to proceed, I've got tens of thousands of log files to process and I need to be able to find three lines that are related to each by the number of lines in between two of them, the makeup of the strings in those lines and a "header" line above them that tells me that the correct sensor type information follows (there can be multiple sensor data in a single log and I have to use a specific set of sensor data). If I can't figure out how to install pcregrep (which seems perfectly suited for the job), I'll ask the underlying question with data.
Your cygcheck -p query indicates that pcregrep is mentioned in those three packages. The online package browser confirms that a pcregrep.exe binary is available in the pcre package: you don't have to compile anything.
Use the Cygwin installer, setup-x86.exe (for a 32-bit Cygwin) or setup-x86_64.exe (for a 64-bit Cygwin), which you've probably used to install Cygwin in the first place, to install the package: when you get to the "Select Packages" step, find pcre in the Text category, click the cycle icon in the New column until a version number appears, and finish the installation. If you no longer have the installer, you can download it from https://cygwin.com/.
Related
I rely a lot on core dumps for finding and fixing rare bugs on my personal applications.
I have multiple versions of my applications installed side by side, and decide which one to run (it depends on some other applications). Only one version of the same tool can run at any given time. My launchers start with "ulimit -c unlimited". When/if the application crashes, a core dump is generated.
One issue is that "file somecoredump" tells me the name of the process generated the core file, but I have no way to know which version of the application generated it, so it's not easy to tell which executable to use.
I'm wondering how this issue can be solved?
I can think of a couple of bad ways:
Embed the version info into the process name, such as MyProcess2.1c. Now "file corefile" tells me the version. Really ugly, I won't consider it.
Every launcher modifies /proc/sys/kernel/core_pattern and sets it to a path with the version info, such as /var/crash/2.1c/core. Ugly, because this setting affects all apps, not just mine. Also it only works now because I only allow a single version of the app to run at the same time, one day I might need to run multiple versions side-by-side.
What would be ideal for me is if there was a way to embed version info into the executable, and retrieve it from the core file. Is this possible?
You can use the strings command in linux to look for unique strings in a binary file. Perhaps you can compile the version into the binary such as this examnple from bash and then grep all the strings output to find it. Just prefix it with a unique string to make it easier to find?:
~]$ strings /usr/bin/bash | grep version
shell_version_string
build_version
sccs_version
rl_library_version
rl_do_lowercase_version
show_shell_version
rl_readline_version
dist_version
GNU bash, version %s-(%s)
GNU bash, version %s (%s)
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
#(#)Bash version 4.2.46(2) release GNU
display-shell-version
-l do not print tilde-prefixed versions of directories relative
HOSTTYPE The type of CPU this version of Bash is running under.
OSTYPE The version of Unix this version of Bash is running on.
version, type `enable -n test'.
do-lowercase-version
.gnu.version
.gnu.version_r
~]$
There is a man page for zipcmp command at http://polarhome.com/service/man/?qf=ZIPCMP&tf=2&of=Cygwin&sf=1. However, I cannot find which Cygwin package contains it at https://cygwin.com/cgi-bin2/package-grep.cgi?grep=zip&arch=x86_64.
as reported on:
https://cygwin.com/packages/x86_64/libzip-tools/libzip-tools-1.5.1-1
the tool and manual is available on libzip-tools package.
No idea why the search is missing the files
I'm running OS X 10.10.5. I'm getting an error trying to open a terminal:
tput: unknown terminal "xterm-256color"
This is obviously a missing termcap entry.
$ port list ncurses
ncurses #6.0 devel/ncurses
Any ideas how to install 'ncurses-term' on OS X?
$ sudo port install ncurses-term
Password:
Error: Port ncurses-term not found
The problem was with an Anaconda package:
https://groups.google.com/a/continuum.io/forum/#!topic/anaconda/XKMFYqM12Vg
It appears there is some problem with an earlier version of the ncurses package that interferes with terminfo
conda install -c r ncurses
Notwithstanding the existence of bloated/monolithic packages on Linux, the package maintainers for ncurses packages often split up the 7Mb of terminfo into "base" and "term" chunks (and separate it from the library). The MacPorts maintainer for ncurses has not done this. The terminal database is part of the "ncurses" package. For instance, I see this from
port contents ncurses#6.0_0+universal
under /opt:
/opt/local/share/terminfo/73/screen.xterm-256color
Also there is a system (non-port) copy here:
/usr/share/terminfo/78/xterm-256color
Applications linked with ncurses will generally use one or the other, depending on whether they are linked with the port- or system-library. However, ncurses can be told to look some other place by setting the TERMINFO variable. If you happen to have copied some customization from another machine into your .bashrc, that could have set TERMINFO.
By itself, tput gives no clue where it is looking for a terminal entry. You can check the output from env to see if TERMINFO is set. The infocmp utility can show where it looks (since late 2011), using the -D option, e.g.,
$ infocmp -D
/usr/local/ncurses/share/terminfo
/usr/share/terminfo
/opt/local/share/terminfo
By the way, OSX does not (barring some specialized ports) use termcap as such. It uses terminfo, as part of some given release of ncurses (see for example the manual page for tgetent).
It's not available in my Cygwin. The "less" command is provided, on the other hand. Maybe the makers of Cygwin think that "more" is just redundant.
I'm curious about that.
Install the util-linux package and you will have "more"
http://cygwin.com/cgi-bin2/package-cat.cgi?file=util-linux%2Futil-linux-2.17.2-1
it does - type which more and you'll get something like this:
/usr/bin/more
If the more command is not available, you could define a symlink to /usr/bin/less, or define an alias. I have Cygwin v1.7.9 installed with literally everything included, it's possible that you have an older version partially installed that doesn't supply more. You can find out what version, you're using like so:
$ uname -a
CYGWIN_NT-5.1 ws-02615 1.7.9(0.237/5/3) 2011-03-29 10:10 i686 Cygwin
Cygwin's installer setup.exe has a search box which allows you to search for utilities you need. Unfortunately this doesn't work if the utility is included in a Cygwin Package in this case you need to use the online search provided here:-
https://cygwin.com/packages/
More is in util-linux (see #joseph) which you can install by typing util-linux into the setup.exe search box (or just linux)
the other package I always need is cygutils-extra as it includes putclip & getclip
I upgrade perl from perl58 to perl588 on Suse Linux.It looks that even though the Config.pm exists for the older version the newer version installation breaks the older version.While the upgrade of Perl on other OSes like HP and AIX does not disturb the older version.
For eg: The perl58 and perl588 versions are present in folder say "/usr/standard_perl" as follows:
/usr/standard_perl/perl58 (directory)
/usr/standard_perl/perl588 (directory)
and have symbolic links pointing to it.
Before and after upgrade the links are as follows:
Before:
perl58_link -> /usr/standard_perl/perl58
After:
perl5_link -> /usr/standard_perl/perl588
perl58_link -> /usr/standard_perl/perl588
perl588_link -> /usr/standard_perl/perl588
Now when i try to run simple "./perl -V" command from /usr/standard_perl/perl58/bin the older version complains of Config.pm not found even though its very well present in its own tree structure.
Is it that in Linux, perl is following a hard coded path for #INC.This kind of behaviour is observed only on Linux.
I am worried for I cannot roll to production for there are scripts that have been running for older version and if this kind of behaviour exists I would need to know if its possible to fix or this is a known behaviour of Linux.
I am not sure could this be because now the older links after upgrade is been pointed to newer version and just linking is not sufficient and need to modify something more on LINUX?
Note:
1.The perl modules are seperately maintained for each version
2.I am not mixing any of the files with previous version.
3. We want all of the old perl scripts running in production servers not to break and use latest version instead for the mainatainence of Perl versions.
3a.Hence a need to tweak the links pointing to latest version instead of their own versions.
Observation:
Only on Linux seeing this behaviour.
One point worth noting is when i twek links of older version to latest version. the #INC automatically is updated for latest version INC and not in LINUX.
Am i missing something here?
I've never seen this problem on Linux. I leave the original perl in its location (/usr/bin/perl), and simply compile my own perl to install to /usr/local/bin (or whatever), and have never seen any breakage of the old version.
You don't say
how you came to have a /usr/standard_perl/perl588 (compiled, given in rpm format or something, pre-compiled tarball, ...)
what options you used when configuring the compilation
You're also very vague with your details - perl58_link, standard_perl, etc. - where is this really? Most of the time it doesn't matter, but sometimes it does.
If you move the link back, do things start to work? If you move the entire 5.8.8 tree somewhere else, do things start to work? Can you recover your base perl from RPM or whatever to try to make it work? IMO, the base perl working is paramount, a secondary perl is always bonus. (I'd take the same opinion of other core unix tools, like shells, awk, sed, or even python or whatever your distro uses for package management. Less so for non-core tools like Java, but if I were running Java apps in production then I'd say the same here, too.)
Leave the system perl executable alone, compile your own, and have your Perl programs run using the one you compiled
All system programs written in Perl should start with:
#! /usr/bin/perl
All non-system Perl programs, user written programs:
This one will use which ever perl executable is found first on $PATH. (same as 'which perl')
#! /usr/bin/env perl
Another option is to specify exactly where the executable you want to use is:
#! /opt/bin/perl
#! /opt/perl/bin/perl
#! /opt/perl/5.10.0/bin/perl
#! /opt/perl-5.10.0/bin/perl
#! /home/$user/perl/bin/perl
#! ~/bin/perl
Or what ever the path to the perl executable is.
Never replace /usr/bin/perl with one you compiled yourself!
I did this once on Ubuntu 7.10, and it broke my system. I could login, and do most everything, but I couldn't change the appearance, for example. I ended up running 'sudo nano $filename' on every Perl program on my computer, and change them so they would run under Perl 5.10, instead of Perl 5.8.
After which I had to install Ubuntu 8.10 from scratch, when it finally came out.
You could also experience incompatibilities if you use cpan or cpanp to install modules, because they could have an incompatible feature change. And for a non-binary compatible perl executable, you have to reinstall all modules that require XSubs.
Thats why all Perl programs that I write I add the header '#!/usr/bin/env perl', and add the path to the Perl executable, to the beginning of the $PATH variable.