Parse error: syntax error, unexpected 'const' (T_CONST), expecting variable (T_VARIABLE)

[scorpio1441]

Parse error: syntax error, unexpected 'const' (T_CONST), expecting variable (T_VARIABLE)

[terrafrost]

The only version of phpseclib that even has "const" on line 67 is the master branch:

phpseclib/phpseclib/Net/SFTP.php

Line 67 in 5833f00

public const CHANNEL = 0x100;

I checked all the branches and the latest released versions of all the branches.

That said, based on the way you're trying to include SFTP.php and the way you're trying to instantiate it, it looks like you're trying to call phpseclib with the v1.0 API. const isn't even used as a keyword in v1.0.

My gut instinct tells me that you're trying to use the latest git version of the master branch with the v1.0 API, which won't work. The API changes from major release to major release. So altho 1.0.x and 1.0.y can be assumed to be backwards compatible (BC) with one another 1.0.x and 2.0.y are not aiming to maintain BC.

The master branch, in particular, is designed to require PHP 8.0+. Or maybe it's PHP 8.1+ idk but it's not even trying to work with PHP 7.0-7.4. phpseclib's 1.0 / 2.0 / 3.0 should work fine on PHP 7.0 - 7.4. Indeed, phpseclib 1.0 / 2.0 / 3.0 are all unit tested on PHP 7.0-7.4 and are all passing:

Latest 3.0 run: https://github.com/phpseclib/phpseclib/actions/runs/7641076373
Latest 2.0 run: https://github.com/phpseclib/phpseclib/actions/runs/7352987304
Latest 1.0 run: https://github.com/phpseclib/phpseclib/actions/runs/7352987015

[scorpio1441]

I tried to run 3.0 and got an exception upon login, no exception handling in docs. Your project is going downwards lately. You are requiring composer, this is the biggest mistake most developers do. Now you require PHP 8+ on master. I had to fall back to lftp.

[terrafrost]

You are requiring composer, this is the biggest mistake most developers do. Now you require PHP 8+ on master.

If I don't utilize composer for dependency management most developers will say I'm making a mistake. If I do use it a small handful of devs, like yourself, will say I'm making a mistake.

Same thing for PHP 8.0 support. I've gotten heat for still supporting phpseclib 1.0, which works on PHP versions as low as PHP 4.4.

Can't please everyone.

That said, if you don't want to use Composer in any capacity what-so-ever or want to use lower versions of PHP then PHP 8.0 then consider phpseclib 1.0 or 2.0.

You can kinda get phpseclib 3.0 and the master branches working, even without Composer:

https://phpseclib.com/docs/install#without-composer

That said, DO NOT use the master branch in prod code. It has an unstable API. 3.0 was a complete BC break from 2.0 and 2.0 was a complete BC break from 1.0. I'm working on changes to how things work in the master branch that will break "BC" with earlier commits but, as I said, I'm not aiming to make the master branch backwards compatible with earlier commits in that branch.

I tried to run 3.0 and got an exception upon login, no exception handling in docs.

phpseclib 3.0 throws exceptions. If you want to learn how to handle them read the PHP docs - not the phpseclib docs.

I will concede, however, that the phpseclib docs could prob do a better at discussing the exceptions that are thrown and when they're thrown. If I got a lot of heat for not documenting them more thoroughly they'd be a higher priority, but you're the first person to have raised an objection about that.

Anyway, I'm closing this ticket. I don't think we're going to see eye to eye on why phpseclib is designed the way it is and there's not really much point to discussing it further.

If you need support with other aspect of phpseclib - for any released version (1.0 / 2.0 / 3.0) - create a new ticket.

[terrafrost]

If you think new versions of phpseclib should support lower versions of PHP then I invite you to debate the matter with the person who created this issue:

#1569

Now, maybe you think the lowest version phpseclib ought to support is PHP 7.0 vs PHP 5.6 (which is the lowest version that the newest version of phpseclib - 3.0 - supports) but still, it stands to reason that the guy who created #1569 prob, at this point, thinks that PHP ought to only support PHP 8.1+ as PHP 8.0 and earlier are now deprecated by The PHP Group.

If you want to defend phpseclib to the death every time someone levels criticism at it for supporting PHP versions as old as it does then maybe I'd be more willing to support old versions myself (altho I will concede that being able to use syntactic sugar introduced in newer PHP versions and not having to work around long since fixed PHP bugs as I do with, among other functions, safe_intval, is quite nice). And even if you did start defending phpseclib's support of old versions, starting today, how long would you continue to do so? I've been developing and providing support for phpseclib for 15+ years. Will you monitor all new phpseclib bug reports and support requests and respond to any criticism about phpseclib supporting older versions of PHP within a few days of its being posted for years to come? I doubt it.

[terrafrost]

One thing you could do that'd motivate me to lower the requirements for the master branch and even to remove the composer dependency would be if you donated, say, $100,000 / year to phpseclib. I'd 110% take flack but for $100,000 / year, I'd be willing to put up with the flack that I'd get, me thinks. That wouldn't require you stay on top of all phpseclib tickets.

That said, do keep in mind that the master branch of phpseclib is probably years away from becoming the 4.0 branch. By the time the master branch does become the 4.0 branch PHP 8.1 is likely going to have been deprecated for years. Altho who knows, maybe PHP 9.0 will introduce some killer feature that'll make me want to make phpseclib 4.0 use that as a minimally required PHP version.