28

There's seems to ready yum package. So I've downloaded the tarball, but as soon as I ran autoreconf -i , I got the following:

configure.ac:14: warning: macro `AM_PROG_AR' not found in library

configure.ac:10: error: Autoconf version 2.64 or higher is required

configure.ac:10: the top level

autom4te: /usr/bin/m4 failed with exit status: 63

aclocal: autom4te failed with exit status: 63

autoreconf: aclocal failed with exit status: 63

So, how can one install jq on RHEL 6.5?

Thank you!

Community
  • 1
Amit Dunsky
  • 485
  • 1
  • 4
  • 10
  • 1
    `Autoconf version 2.64 or higher is required` sounds pretty self-explanatory. – ceejayoz Apr 04 '16 at 13:20
  • 2
    Maybe so, but this is an issue of itself. How can Autoconf be upgraded? This too won't go straightforward fashion... – Amit Dunsky Apr 04 '16 at 13:58
  • Have you considered using one of the ready-made binaries on the jq releases page? https://github.com/stedolan/jq/releases/download/jq-1.5/jq-linux64 – ceejayoz Apr 04 '16 at 14:54

3 Answers3

50

As it says on the development page for jq "jq is written in C and has no runtime dependencies". So just download the file and put it in place with the following: 

wget -O jq https://github.com/stedolan/jq/releases/download/jq-1.6/jq-linux64
chmod +x ./jq
cp jq /usr/bin
Joe
  • 1,023
  • 8
  • 11
  • I used the URL provided by for https://stedolan.github.io/jq/download/ for 64-bit linux. To get wget to work I had to add the `-O jq`. The full command was: `wget -O jq https://github.com/stedolan/jq/releases/download/jq-1.5/jq-linux64` – Philippe Jul 14 '16 at 15:02
  • 1
    -O just specifies the output name of the downloaded object. Without specifying it, it should use the name supplied by the URL which in this case is 'jq' so it shouldn't be necessary to add that. I wonder if your version of wget is different somehow in requiring that. – Joe Jul 18 '16 at 22:44
  • HTTPS is now supported on github.io => [https://stedolan.github.io/jq/download/linux64/jq](https://stedolan.github.io/jq/download/linux64/jq) – Beni Cherniavsky-Paskin Oct 27 '16 at 09:52
  • 1
    Updating link address for v1.5: https://github.com/stedolan/jq/releases/download/jq-1.5/jq-linux64 – SaxDaddy Dec 08 '16 at 21:05
  • Thx @SaxDaddy Since the new version now has it labeled jq-linux64 I did add the -O jq option so it still has the easy naming. – Joe Dec 08 '16 at 21:29
  • 1
    Downvoted for using unsigned, pegged version. Should use EPEL. – nate Mar 23 '18 at 15:45
  • 1
    @nate EPEL works. But getting the file directly from the source works also, and can ensure you get the latest version if you want. I just updated link to point to version 1.6 which was just recently released – Joe Nov 26 '18 at 21:59
  • 2
    EPEL for RHEL 6 only has 1.3 available for example. – Joe Nov 26 '18 at 22:08
  • @Joe Look at what *just* happened with npm / event-stream to understand why this is still very, very bad. – nate Nov 28 '18 at 21:38
26
yum install -y epel-release

yum install -y jq
danday74
  • 851
  • 10
  • 10
16

jq is in the EPEL repository, which you should already have enabled.

Once you have enabled EPEL, you can just yum install jq like everything else.

Community
  • 1
Michael Hampton
  • 237,123
  • 42
  • 477
  • 940
  • 3
    +1 for not downloading unsigned http stuff. – Florian Heigl Aug 15 '16 at 21:34
  • The trouble is that the epel one, like everything epel, is out of date if you rely on any of the "newer" features of jq (like the regex support added in jq 1.5 way back in 2015). The statically linked binary is probably the better way to install it (use something like fpm - https://github.com/jordansissel/fpm - to create an RPM out of it). – Jon V Jan 26 '17 at 21:30
  • 1
    @JonV This is intentional; people who intentionally choose an older distro generally don't want the newer features but would rather have "more stability" instead. In EPEL 7 you will find jq 1.5. – Michael Hampton Jan 26 '17 at 21:34
  • @MichaelHampton - maybe, however if you're looking for stability, EPEL is _not_ the place to find it. We were burned recently on a library circular dependency that someone uploaded into EPEL that was not resolveable without explicitly ignoring dependencies. – Jon V Feb 14 '17 at 23:20
  • @JonV You speak as if that is some sort of regular occurrence that is guaranteed to happen, rather than a bizarre and rare event. It's for such events that we test updates anyway. – Michael Hampton Feb 14 '17 at 23:24
  • Happens more frequently than I'd like, although I can count them on one hand. It's the best alternative I know of but I don't think it's great. – Dan Pritts Oct 02 '17 at 19:27