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
Related
I have installed gprbuild, xmlada, and gnatcoll. I am now attempting to install gnatcoll_postgres. Which I have downladed from here: https://github.com/AdaCore/gnatcoll-db/
Within the Postgres folder is a Makefile, which I execute like so...
[parallels#localhost postgres]$ ls
gnatcoll_postgres.gpr gnatcoll-sql-postgres-gnade.ads
gnatcoll-sql-postgres.adb gnatcoll-sql-ranges.adb
gnatcoll-sql-postgres.ads gnatcoll-sql-ranges.ads
gnatcoll-sql-postgres-builder.adb Makefile
gnatcoll-sql-postgres-builder.ads postgres_support.c
gnatcoll-sql-postgres-gnade.adb README.md
[parallels#localhost postgres]$ make Makefile
which: no gnatls in (/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin:/var/lib/snapd/snap/bin:/home/parallels/.local/bin:/home/parallels/bin)
make: Nothing to be done for `Makefile'.
[parallels#localhost postgres]$
Would anybody please be able to tell me what this means...
which: no gnatls in (/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin:/var/lib/snapd/snap/bin:/home/parallels/.local/bin:/home/parallels/bin)
make: Nothing to be done for `Makefile'.
Any help would be greatly appreciated.
Please see the xmlada and gnatcoll in my project below, does this look like it's installed correctly? I'm presuming this isn't correct...
Thanks,
Lloyd
It means that your GNAT installation binaries aren’t on your PATH.
The README.txt from the adacore.com site says, in part,
To start using the tools in command-line mode, you will need to add
{install_prefix}/bin
to your PATH environment variable. Alternatively, you can simply launch
{install_prefix}/bin/gps
and GPS will automatically add itself to the PATH - it will also find the
cross compiler, if you have installed everything in the default locations.
Note that GPS will add this at the end of the PATH, meaning that it will find first any other GNAT installations that you have in your PATH.
I strongly suspect that you’ve been doing the latter, so that GPS adds itself (actually, of course, its own location) to the PATH, so that when it launches the compiler it finds the correct one.
When you run make from the terminal, the compiler isn’t on the PATH, so neither are gnatls, gprconfig, gprbuild and the rest of the GNAT tools.
What you need to do is to take the first choice from the README, and add /home/parallel/opt/GNAT/2019/bin to (the front of) your default PATH. How you do that depends on your shell.
You will find xmlada, gnatcoll already installed.
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 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/.
I use gnumake version GNU Make 3.81 under cygwin on windows. Cygwin version is CYGWIN_NT-6.1-WOW64 1.7.7(0.230/5/3) 2010-08-31 09:58 i686 Cygwin
In my makefile used to build the source, when i say VERBOSE=yes, i still do not see detailed commands and options used to compile,link the code. So basically VEROBSE=yes behaviour seems to be same as VERBOSE=no.
Pls. note that the compiler (sparc-elf-gcc) which the make command invokes, is configured with --verbose option. I verified that by checking sparc-elf-gcc -v .
Is this switch removed/deprecated for this particular gnumake/cygwin versions or any pointers on how I can see details of the make/compile/link commands.
thank you.
-AD.
The verbose options are not symetrical. If you turn them off in one place they are off and can not be turned on somewhere else.
Have you a # in front of your commands? This also makes commands silent.
I think this could help you :
make VERBOSE=1
It will show the details of the compilator commands
Have you tried:
make V=1
It works in Linux with GNU Make 3.82
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.