Jump to content

philip_petev

philip_petev

Member Since 13 Oct 2006
Offline Last Active Today, 03:53 PM
*****

Posts I've Made

In Topic: Build_Clover.command, another Script to build standard Clover (or customized)

25 November 2016 - 05:42 AM

I see word "flipped" more user friendly than "reversing". But, as we still have internet connection, can we print out the URL for users?
 

Spoiler

 

 
No point in this. The purpose of that subroutine is to download the script and send it to stdout (the display), so the commands that follow ( | grep '^SCRIPTVER="v' | tr -cd '.0-9' ) could extract the version number from that output. That version number is being used later for comparison with the version number from the local copy of the script. The user don't need to download it, at least not at that point.
 

What if an old version of curl w/o ssl and redirect capabilties get "installed one way on another" the same way happened to you for wget?


That's also possible, but if you are so concerned about that, why don't you just hardcode the path to the stock binaries to ensure that exactly they will be used and nothing else? The stock curl in OS X is located at /usr/bin, as well as the stock wget in Linux. All it takes is two additional variables:

WGET=/usr/bin/wget
CURL=/usr/bin/curl

and so the corresponding lines will become:

if [[ -x $CURL ]]; then
            RSCRIPTVER='v'$($CURL -v --silent $GITHUB 2>&1 | grep '^SCRIPTVER="v' | tr -cd '.0-9')
        elif [[ -x $WGET ]]; then
            RSCRIPTVER='v'$($WGET $GITHUB -q -O - | grep '^SCRIPTVER="v' | tr -cd '.0-9')
        else
            return
fi

In Topic: Build_Clover.command, another Script to build standard Clover (or customized)

24 November 2016 - 07:20 PM

naaah! The only bug here is your wget. What if an old version of curl w/o ssl and redirect capabilties get "installed one way on another" the same way happened to you for wget? 

Did you realize that what you post here show a big mistake by someone? (don't know if you runned a package or installed it via something like macports (here is the problem))

We are nearly to 2017, so why you want bring back your OSes to the 1990?

For me you can install what you like, but claim a bug to this script where ther's no bug considering that also wget itself really does not have this issue since works really fine ins OSX (no need to be ported, just configured), so why not use this attachicon.gifwget_1.18.zip that I downloaded and properly compiled in more or less 60 senconds?  :wink_anim:

Off course the statement should be reversed, but in Debian will give you similar problems with curl due to known problem with libcurll3 (Debian get released each two years). That's why I can't

 

I don't remember I've claimed there is a bug in the script, that are your words. What I said is the problem is in wget and that's a different thing. Also, I don't remember I've said that I've installed it (for the third time in case you haven't seen the previous two: I have no idea how that binary appeared there), also your words. The binary is located in /usr/local/bin and I really have macports installed(which has no installed wget port, because I've never needed it), but its folder is at different location (/opt/local/bin), so obviously I haven't installed it (but I think I've mention it several times). It seems we're talking about two different thing all the time...

If you wanted wget so bad, you could have made the script to download and install it in OS X by now, but I don't understand why would anyone do that for operation that dowloads some content and sends it to stdout (because that's the only purpose of those line) and there is one, already preinstalled, tool like curl that is quite sufficient for that job. I've already deleted that faulty binary, but the potential problem remains.

 

"We are nearly to 2017, so why you want bring back your OSes to the 1990?"

Didn't get that and what exactly has to do with the situation. Really.

 

Look, I really respect you, but all I've seen from you in the last several posts is words I've never said, most of them an attempt of an interpretation of my words, not to mention omitting most of the facts that I've written (intentionally or not) and I don't get what I've done to deserve such attitude. It seems you are more concerned about potential (yes, potential) problems with Linux that such problems with OS X. So, I'm not trying to convince you of anything. That topic is done for me.

In Topic: Build_Clover.command, another Script to build standard Clover (or customized)

24 November 2016 - 06:15 AM

 

 

very simple,

curl is certainly installed in OS X so that the above statement cannot be an OS X affair. the statement will never be satisfied.

in linux instead, wget, unlike curl, is part of the GNU project and is surely preferred. but can be only available as optional in some distros....

if [[ "$SYSNAME" == Linux ]]; then
    if [[ "$(uname -m)" != x86_64 ]]; then
        printError "\nBuild_Clover.command is tested only on x86_64 architecture, aborting..\n"
        exit 1
    fi

    # check if the Universally Unique ID library - headers are installed
    if [[ "$(apt-cache policy uuid-dev | grep 'Installed: (none)')" =~ 'Installed: (none)' ]]; then
        aptInstall uuid-dev
    fi
    # check if subversion is installed
    if [[ ! -x $(which svn) ]]; then
        aptInstall subversion
    fi

    # check whether at least one of curl or wget are installed
    if [[ ! -x $(which wget) ]] && [[ ! -x $(which curl) ]]; then
        # ok both of them are no currently installed, we prefear wget
        aptInstall wget
    fi
fi

...as you can see this only happen if the OS is LINUX, and not for OS X. So sorry, wont fix, I can see the bug only in your system since your wget it's against the security policy on latest Apple OSes, imho unusable (macOS will deny non https links), that's why I think you should remove it or upgrade it. The script can use both of them, but sure to manage ssl connections you need programs that support the https protocol.

 

:yes:


agreed

 

 

Not exactly my point. My point was the current script logic prefers wget over curl even in OS X, so in case like mine (wget, installed somehow in OS X, which BTW I don't even use) it will be used instead. So my suggestion is simple, this part:

if [[ -x $(which wget) ]]; then
            RSCRIPTVER='v'$(wget $GITHUB -q -O - | grep '^SCRIPTVER="v' | tr -cd '.0-9')
        elif [[ -x $(which curl) ]]; then
            RSCRIPTVER='v'$(curl -v --silent $GITHUB 2>&1 | grep '^SCRIPTVER="v' | tr -cd '.0-9')
        else
            return
fi

to be flipped like this:

if [[ -x $(which curl) ]]; then
            RSCRIPTVER='v'$(curl -v --silent $GITHUB 2>&1 | grep '^SCRIPTVER="v' | tr -cd '.0-9')
        elif [[ -x $(which wget) ]]; then
            RSCRIPTVER='v'$(wget $GITHUB -q -O - | grep '^SCRIPTVER="v' | tr -cd '.0-9')
        else
            return
fi

Modified this way, the script will use curl by default in OS X (which already comes preinstalled), avoiding any wget version (good one or not), installed one way on another. It will try to use wget only if curl hasn't been found for one reason or another (which is highly unlikely). In Linux, the script won't find curl (not installed by default in 98% of the cases) and wget will be used instead.

 

Let's not forget the script is made to ease the Clover building process primarily in OS X !!!

In Topic: Build_Clover.command, another Script to build standard Clover (or customized)

22 November 2016 - 10:07 PM

*Cannot be done. curl is not installed on linux by default, and wget is not installed by default in macOS X

 

 

Sure it can:

if [[ ! -x $(which wget) ]] && [[ ! -x $(which curl) ]]; then
        # ok both of them are no currently installed, we prefear wget (???) why should we limit ourselves with only wget, why don't we install both
        aptInstall wget
        aptInstall curl
    fi

:D

Installing curl in Linux will be much easier (both Debian and Ubuntu have that package, a matter of 150 KB package) than finding and/or compiling a proper copy of wget for macOS.

Also, the current script checks for wget first and then for curl (so if found, wget will be used instead of curl, no matter if the wget copy, found by the script, is good or not) and IMO for macOS should be quite the opposite. Changing that order won't be a problem for Linux at all, wget will be used anyway, if curl is not found.

 

Frankly, I have no idea how exactly that wget version has come to me, but you're right, it's definitely not preinstalled, it can't be, because the tools, preinstalled with macOS, are living in /usr/bin, not in /usr/local/bin.

In Topic: Build_Clover.command, another Script to build standard Clover (or customized)

22 November 2016 - 03:07 PM

Not that easy:

Last login: Tue Nov 22 17:10:33 on ttys000
philip@iHack:~$ wget https://raw.githubusercontent.com/Micky1979/Build_Clover/master/Build_Clover.command
https://raw.githubusercontent.com/Micky1979/Build_Clover/master/Build_Clover.command: HTTPS support not compiled in.
philip@iHack:~$

That happens on both my laptop and my desktop, so it's definitely a wget issue. I think that error speaks very clear for itself.

© 2016 InsanelyMac  |   News  |   Forum  |   Downloads  |   OSx86 Wiki  |   Mac Netbook  |   PHP hosting by CatN  |   Designed by Ed Gain  |   Logo by irfan  |   Privacy Policy