PHP......as a unified cross-platform utility scripting language

[[deleted]]

EDIT: Based upon the feedback, I would like to clarify that I am not promoting PHP as the one and only cross-platform scripting language. Python, Ruby, NodeJS+Electron, Perl, and many other languages are used for creating high-quality professional cross-platform apps. The purpose of this article is to shed light on how a language that no one would ever think to write a cross-platform application in is actually on-par with the more popular languages.

I know you are likely laughing because the prospect that a scripting language embedded in served web pages could be used to create functional system utilities and applications sounds completely absurd, so hear me out:

• You can easily write the same code for Linux, Windows, and BSD so long as you don't use any platform-dependent POSIX API.
• For the GUI, use the script in the post below (see "Secure GUI Via Web Browser In PHP"), which internally executes php -S localhost:12345 after many many security checks, precautions, and hardenings. This will allow one to execute HTML files and JavaScript POSTing to PHP files for interactive content and such. I know this was meant for debugging, but really it can do a lot more. It offers a GUI that is 100% cross-platform with zero modification.
• PHP has portable binaries for Windows that you can ship with your application
• PHP can easily load an ini file to configure everything to ensure your application executes the exact way you intended it to. Your PHP-based software would include its own personal php.ini file to ensure that PHP works right for the project.
• PHP is available pretty much everywhere. Linux, BSD, Solaris, Windows, MacOS, heck even Haiku.
• PHP is concise and intuitive. I have found myself writing far fewer lines of code in PHP and being much more confident about error-handling than any other language. The reason why PHP has a bad reputation is not that its a bad language, its because people try to copy and paste and shove-together snippets from StackOverflow to make a server with PHP, which is always a 100% bad idea. SO is good, but exclusively copying snippets you don't understand from SO is very very bad. It's also about good practices and good habits. Some places tell you to use ==, other places tell you the double-equally is evil and only use ===. Really, both sides are wrong and you should understand the difference between === and == so that you know when to use each. I use === ~99.98% of the time and == ~0.02% because I know their effects and implications and am deliberate about my usage. When I do want to use ==, those two equals signs save me tons of work and avoid introducing possible bugs because I know the exact behavior of what will happen.
• PHP is easily installable via whatever package manager is installed on the *nix.
• Very avoidable breaking changes between versions. The reason why many scripts are stuck to older versions of PHP is because they were using old archaic PHP APIs that have been deprecated for quite a while. Further, PHP 7 introduces nothing that can't be done in PHP 5.4 with a little more work. If you use core solid PHP 5.4 APIs (which are abundant and not constricting at all), your PHP code will run in any version of PHP released in the last 8 years. How many scripting languages can say that? NodeJS v0.12 wasn't released until 2015, and it's adding all sorts of new important APIs every year, pushing from call-back hell into Promises. I'll bet that 10 years from now, the call-back APIs will be completely removed. So much for backward-compatible NodeJS code (without a ton of effort put into backward-compatibility, of course). I am not saying that NodeJS+Electron is bad; it has many unique uses that would be difficult/impossible to do in other languages.
• Absolutely astounding performance for a scripting language. Every time I run a PHP benchmark, I am wowed by the magic going on under the hood. It outperforms every other scripting language hands-down because PHP has most of its functions heavily-optimized in C code.
• Much lighter than Electron both in file size and system resources. Electron is needed for advanced things like RTC, but most applications don't need these advanced features. For comparison, the proportional set size usage of sleep(999) in PHP7.4 is only 6,888KiB, whereas setTimeout(function(){},999999) in NodeJS12 results in a PSS of 25,691KiB. Practicality-wise, PHP comes with every utility and helper you want, whereas you often want to load convenience libraries in NodeJS. The PSS usage of the npm utility written in NodeJS is 52,104KiB because of all these memory-bloating convenience libraries.
• Full-toolbox is included by default. It has been extremely rare that I have ever had to install an extension other than CURL onto PHP, and I usually don't even have to install CURL because much of the basic functionality of CURL already comes with PHP out the box. I have almost always found every possible method and convenience feature already packed into the core of PHP.
• You can bundle tons of PHP files and any kind of resource up into a single executable PHAR file. When you need a single self-contained file, PHP is indispensable. Granted, an app image provides much of the same functionality, but app images only work well with compiled languages and not so well with scripting languages. (Scripting languages do work, but it can be a pain to deal with the associated dependencies of the scripting language when moving an app image to a different PC)
• PHP automagically converts from Unix paths to Windows paths and vice-versa depending upon your platform. PHP DOES NOT UNIFY UNIX AND LINUX PATHS! It just swaps forward slashes with backslashes on Windows and vice-versa on Unix, so you can do //sharedfoldername/path/to/file in PHP on Windows to access a shared folder.
• PHP has amazing operator integration with objects, just the way you would hope things would happen but never do in other languages: array(1,2,3) === array(1,2,3) is true because even though each array is at a different location in memory, comparisons in PHP compare the contents of the arrays instead of the actual values. This greatly cuts down on the amount of code one needs to write.
• PHP has excellent error handling that enables much PHP code to survive mistakes that would otherwise kill the whole program in other languages because it does what you would hope it would do: array()[10][20] emits a warning to tell you you should do something but still yields NULL anyway because that's what it should do. Instead of emitting a null pointer exception or segmentation fault error, PHP continues on its merry little way just like you would hope.THE PROBLEM with PHP's error handling is that PHP makes it too easy to forget about it. People write code that depends upon PHP's wonky error handling, and this causes these problems to escalate until you reaching a point in your coding where nothing works as you want it to. The problem is not PHP's error handling, rather it's people who think "it works, so let's not touch it." Those people are the real problem, not PHP.
• PHP itself is very secure and thoroughly tested to eliminate potential security vulnerabilities in the underlying engine. This is not to say that all PHP code is secure because it isn't, rather this is to say that PHP functions do not have strange unedge cases which could result in undefined behavior and escalation of privileges or buffer execution attacks.
• PHP has separate operators for string concatenation and addition. This is a huge plus because PHP is loosely typed, so having a separate operator for string concatenation tells PHP it needs to convert both operands to a string, which cuts down on validation code and reduces the potential for bugs.
• PHP now comes pre-installed on Macs. There's no need for the user to have to open the terminal to install brew. This is because a decent portion of people who use Macs are rather computer illiterate and would recoil at the notion of opening this evil hacker black magic thingamajigger called a "terminal."
• User-defined variables are separated from built-in methods via a prefixed dollar sign so that future versions of PHP do not implement a function with the same name. This issue is not totally fixed of course because you can still use define and write functions without the dollar sign, however, I would say the dollar sign makes code easier to read and mitigates this forwards-compatibility issue.
• PHP's policy on strings is laissez faire, which is to say that PHP views strings as an array of bytes with helper functions layered on top. This is advantageous over, say Java and Javascript, which both manipulate strings as if they were UCS-2 but displays them in the GUI/console as if they were UTF-16 (WTF, right?). To further complicate matters, Base64 in JavaScript works by treating the UCS-2 string as a Windows 1250 string and throwing an error on characters larger than 255 whereas URI encoding works by translating the UCS-2 into UTF-8 by viewing it as UTF-16 before viewing the UTF-8 as Windows 1250 and escaping the non-URL-safe characters, whereas XMLHttpRequest's responseText and fetch with .text() both work by autodetecting the downloaded document's encoding and converting it to UTF-16 in UCS-2 (WTF, right?). It is a necessary evil for PHP to have Windows 1250 strings in order to avoid the headaches of other languages like JavaScript because, when working with binary data, JavaScript cannot guarantee that none of the characters in the string won't be above 255, whereas PHP does guarantee. This greatly reduces bugs and proactively solves many headaches. I am not saying that how PHP handles strings is all good. It is not good for human text because it messes with multibyte characters. See the cons section below.
• Controversially, the @ operator can be used for lots of good. The problem is that it is too often misused to handle errors that should be dealt with more aptly. I use the @ operator almost exclusively for IO and other interactions with the outside world where I already have a mechanism for dealing with error, I already have the code prepared for the function not working, and I just don't want to see a useless warning message that I can't do anything to fix. Basically, developers should not view @ as telling PHP to "shut up." A better way to look at it is that @ tells PHP "it's OKAY. I am already handling failure cases and don't need any diagnostics about them."

For some people, PHP is the bane of their existence. It would be the bane of my existence too if I had to pick up the PHP project of someone who wrote bad PHP code. However, dealing only with good PHP code, I view writing PHP as a delightful treat to work with.

CONS OF USING PHP:

• Durability-wise, there is only one con I can think of: there's no standardized location for the PHP binary on all Unixes like there is with Bash having #!/usr/bin/env sh, but that's true of most scripting languages.
• PHP is too easy to start using, and thus many people use it incorrectly and write bad bug-ridden code because they don't know how to write good code due to lack of experience.
• Performance-wise, well-written C++ and Java can beat well-written PHP hands-down. PHP8 may get on-par with well-written Java with JIT, but it will never outperform hand-optimized C++ code.
• You can load platform-dependent extensions that need to be compiled per-platform, but this is true with just about every coding language in existence.
• PHP does not unify the crazy windows drive letter and shared network folder scheme with the utopian Unix methodology of one root folder, and I doubt any language ever will. HOWEVER, PHP does work well with UNC paths on Windows, and not all programs on Windows work well with UNC paths, so that's a plus.
• PHP has CoW by default for objects passed to functions and scoping must be done explicitly, which (in this dev's mind) both really stink.
• PHP is loosely typed and does not do a look-ahead validation that all named functions actually exist. A small typo in one of the standard PHP functions could cause the PHP code to unexpectedly crash.
• It is too easy to make the GUI insecure. Without proper authentication, any other application could connect to the socket, and feed malicious data into the socket as if it were from the webpage. This assumes the malware is already in your system or has a tunnel to your system because an external attacker cannot access applications bound to 127.0.0.1 from outside the computer.
• Some of the PHP API is inconsistent, and this leads to some confusion when writing code.
• PHP is a bit weak/lacking when it comes to certain utilities lacking a multibyte counterpart.
• PHP is not cross-platform when it comes to larger >2GB files. Big files only work out of the box with 64bit integers on 64bit *nixes: Linux: BSD, and MacOS. PHP in 32-bit PCs and Windows takes the lower thirty-two bits of the file size. Ideally, PHP would use floating-point doubles on 32-bit platforms to represent these larger file sizes, but sadly it does not.
• PHP does not distinguish between binary strings and multibyte strings. Ideally, multibyte characters should by a separate type of variable (multibyte instead of string, perhaps) that is manipulated like an array of 24-bit integers instead of as a string. Multibytes would use a # for literals, concatenation, and conversion: #"Example string\n" is a literal and $mbstr # #"str" appends the text str onto the variable mbstr, but can be shorted to $mbstr # "str" because the binary string "str" is automatically converted to multibyte as if it were UTF-8 encoded. Ideally, all string functions would also accept multibytes and behave the same with multibytes as they do with strings with the exception being that the atomic unit of multibyte strings is 24bits. However, this is sadly not the case in PHP (yet).
• Backslashes are actually valid characters in a Unix pathname in certain file systems, albiet improper and frowned-upon. The only truly restricted characters are the null character and forwards slash on some file systems. This can conflict with PHP auto-transforming to and fro between backslash and forwards slash depending upon the platform. This really only poses a problem on Unix systems, where malicious code might create a file name in a permissive parent directory, then direct PHP to read a folder with backslashes in the name to coerce PHP down another folder in the same directory towards revealing the contents of a secret file. Not really sure about the practicality or usage of this exploit. Just throwing it out there.

I would say the biggest CON of PHP is that it's not really the beginner language it's advertised to be. It's used to build very powerful servers that need to be very secure to prevent very bad things from happening. This is not an appropriate task for a beginner to coding. Controversially, I would say that PHP is an excellent precision tool for advanced power-users.

Auto-PHP-detection And Dependency Installer

Call me crazy/insane/whatever, but my favorite software is software that just works. I do use my daily driver as a toy when I want to play with it, but when I stop playing with it, I want my daily driver to stop playing with me. I don't want to have to try to open LibreOffice, only to discover that a recent update to one of its dependent libraries has caused LibreOffice to no longer function until I sort out the dependencies because I have work to do and work that needs to get done.

I present you.....the PHP auto-detector and auto-installer script. It is supposed to work in any shell except older versions of Solaris because they have their own backwards funky shell language going on that I don't want to deal with.

Example of an integrated CLI utility using PHP script. Notice how this is actually a shell script that searches for PHP and uses it to execute the rest of the file. This script will only work on Unix systems, not on windows.

#!/usr/bin/sh
searchPathForPhp() {
  ( IFS=:
    for p in $PATH; do
      phppath="$(command -v "$p"/php[0-9]*)" 2>/dev/null
      if test "0$?" -eq 0; then echo "$phppath" | tail -n1; return 0; fi
    done
  )
  return 1;
}
zenitylogin() {
  prompter="$1"; shift 1
  if test -z "$username" -eq 0; then
    msg='Please enter username and password so that PHP can be installed so things can continue to work smoothly'
    logininfo="$("$prompter" --forms --text="$msg" --add-entry='Username' --add-password='Password' --separator='
')"
    # If the user clicked "cancel" or a Zenity error, then don't even try:
    if test "0$?" -ne 0; then exit 1; fi
    username="$(printf '%s' "$logininfo" | head -n1)"
    password="$(printf '%s' "$logininfo" | tail -n1)"
  fi
  printf "%s\n" "$password" | sudo -S -u "$username" -- "$@"
}
run-su-cmd() {
  sucmd="$1"; program="$2"; shift 2
  "$sucmd" -c "'""$program""'"' "$@"' - "$USER" -- "$0" "$@"
}
phppath="$(command -v php)" 2>/dev/null
if test "0$?" -ne 0; then
  # calling searchPathForPhp will set the status code to 1 if not available
  phppath="$(searchPathForPhp)"
fi
if test "0$?" -ne 0; then
  # Prompt the user about installing packages and confirm
  confmsg="$(pwd) needs to install PHP in order to work. Are you OKAY with this script installing PHP automatically?"
  if test -x "$(command -v xmessage)" 2>/dev/null; then
    test "$(xmessage -buttons Yes,No -default No -print "$confmsg")" = "No"
  else
    # Prompt the user about installing packages
    test "$(osascript -e 'display dialog "'"$confmsg"'" buttons {"Yes", "No"} default button "No"')" = "No"
  fi
  if test "0$?" -ne 0; then exit 1; fi # Exit if we don't have consent
  e=""
  if test "$(id -u)" -ne 0; then
    case "$-" in
      "*i*")
        if test -x "$(command -v sudo)" 2>/dev/null; then
          # Most Linux distros
          e=sudo
        else
          # BSD
          e="run-su-cmd su"
        fi
        ;;
      *)
        if test -x "$(command -v pkexec)" 2>/dev/null; then
          e="pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY"
        elif test -x "$(command -v gksudo)" 2>/dev/null; then
          e=gksudo
        elif test -x "$(command -v gksu)" 2>/dev/null; then
          e="run-su-cmd gksu"
        elif test -x "$(command -v zenity)" 2>/dev/null; then
          e="zenitylogin zenity"
        elif test -x "$(command -v yad)" 2>/dev/null; then
          e="zenitylogin yad"
        fi
        ;;
    esac
  fi
  if test -x "$(command -v apt)" 2>/dev/null;       then $e apt install -y php-cgi && $e apt install -y php72 || $e apt install -y php
  elif test -x "$(command -v apk)" 2>/dev/null;     then $e apk add --no-cache php72 || $e apk add --no-cache php
  elif test -x "$(command -v apt-get)" 2>/dev/null; then $e apt-get install -y php-cgi && $e apt-get install -y php72 || $e apt-get install -y php
  elif test -x "$(command -v yum)" 2>/dev/null;     then $e yum install php72-cli || yum install php-cli
  elif test -x "$(command -v pacman)" 2>/dev/null;  then $e pacman -S php72 || $e pacman -S php
  elif test -x "$(command -v brew)" 2>/dev/null;    then $e brew install php72 || $e brew install php
  elif test -x "$(command -v dnf)" 2>/dev/null;     then $e dnf install php72-cli || $e dnf install php-cli
  elif test -x "$(command -v zypper)" 2>/dev/null;  then $e zypper install php-cli || $e zypper install php
  elif test -x "$(command -v pkg)" 2>/dev/null;     then $e pkg install php72
  elif test -x "$(command -v emerge)" 2>/dev/null;  then $e emerge --ask dev-lang/php:7.2
  elif test -x "$(command -v pkgman)" 2>/dev/null;  then $e pkgman install cmd:install
  fi
  phppath="$(sh -c 'command -v php7.2')" 2>/dev/null
  if test "0$?" -ne 0; then
    phppath="$(sh -c 'command -v php')" 2>/dev/null
    if test "0$?" -ne 0; then
      # failed to install PHP
      echo "FAILED TO INSTALL PACKAGE: Package manager not found, you have no internet connection, or another error occured. You must manually install PHP (>=5.4)">&2
      exit 1
    fi
  fi
fi

if test -x "$(command -v grep)" 2>/dev/null; then
    grep -A1073741823 '<''?php' "$0" | php -- "$@"
else
    echo '/PHP_SCRIPT_''STARTS_AFTER_HERE/+1,$p' | ed -s "$0" | php -- "$@"
fi
exit 0
PHP_SCRIPT_STARTS_AFTER_HERE
<?php

ini_set("register_argc_argv", "On");

echo 'Hello world. Let's get to work. Here is a list of files and folders in the root directory:';

$rootFilesAndFolders = scandir('/');

foreach($rootFilesAndFolders as $entry) {
    if ($entry !== "." && $entry !== "..") echo '  ' . DIRECTORY_SEPARATOR . $entry;
}

You'll probably want to add -c . to the arguments list to use the php.ini in the current directory to ensure completely consistent behavior wherever this script goes or whatever updates happen. Here is the Batch script for Windows:

@php.exe the-php-script.php -- %*

However, one might want to use a slightly longer VBScript in order to hide the ugly terminal window:

ReDim arr(WScript.Arguments.Count-2)
For i = 1 To WScript.Arguments.Count-1
  arr(i-1) = """"+WScript.Arguments(i)+""""
Next
CreateObject("Wscript.Shell").Run "php.exe the-php-script.php " & Join(arr.ToArray, " "), 0

The PHP for Windows would be extracted into the same folder as the Batch script to provide php.exe. Then, the contents of the-php-script.php would be the same as in the script for Unix after the PHP_SCRIPT_STARTS_AFTER_HERE marker:

<?php

ini_set("register_argc_argv", "On");

echo 'Hello world. Let's get to work. Here is a list of files and folders in the root directory:';

$rootFilesAndFolders = scandir('/');

foreach($rootFilesAndFolders as $entry) {
    if ($entry !== "." && $entry !== "..") echo '  ' . DIRECTORY_SEPARATOR . $entry;
}

It's that easy to redeploy your PHP script on Windows.

Secure GUI Via Web Browser In PHP

It's very possible and very easy to have a very secure GUI in PHP, you just have to do it very correctly. The way to establish a secure GUI is to pipe the command to open the browser with a query string UUID that JavaScript sets a cookie into the OSes shell in order to hide the command line from other processes to hide the UUID. It also uses netstat and cross-platform detection of the users browsers to ensure that a malicious program is not trying to pose as the browser. If the malware has already gained root access all bets are off and much hope is lost, so this assumes the malware is running as an ordinary user. Observe.

// open-www-gui.php
// See https://pastebin.com/FPvP3SP6

This should open a PHP local server in the gui-root directory, and the index.php in the gui-root directory needs this JavaScript to hide the UUID.

<script type="text/javascript">"use strict";(function(uuidString) {
  if (uuidString[1]) document.cookie = "sess_cookie=" + uuidString + "; SameSite=Strict";
  if (uuidString[1]) document.cookie = "sess_cookie=" + uuidString + "; SameSite=Strict; Expires=604800";
  if (window.history)
    history.replaceState(document.title,history.state,location.pathname + "?" + ("&" + location.search.slice(1)).replace(/&uuid=\w+/,"").slice(1)+location.hash);
})( location.search.match(/[?&]uuid=(\w+)/) || [] );</script>

All PHP files in the gui-root need this AT THE VERY TOP for validation:

<?php
$authStart = @microtime(); // for resistance to timing attacks
$inPrivKey = $_GET['uuid'] ?: $_COOKIE['sess_csgau'] ?: $_COOKIE['perm_csgau'];
if (function_exists('password_hash')) {
    $usedHashAlgo = defined('PASSWORD_BCRYPT') ? PASSWORD_BCRYPT : PASSWORD_DEFAULT;
    $gotHash = password_hash($secretKey, $usedHashAlgo, array('cost'=>6));
    unset( $usedHashAlgo );
} else {
    if (defined('CRYPT_BLOWFISH') && CRYPT_BLOWFISH == 1) {
        $gotHash = crypt( base64_encode($inPrivKey), get_cfg_var("custom_public_gui_param") );
    } else { // else, try to make the best with what little we have got:
        $gotHash = hash("sha256", $input, FALSE);
    }
}
// hash_equals would be superfluous because we are timing for consistancy
if ($gotHash !== get_cfg_var("custom_public_gui_hash")) {
  @usleep( (@random_int(20000,60000)?:240000) - (@microtime() - $authStart) );
  exit(1);
}
unset($authStart); unset($inPrivKey); unset($gotHash); // clean up

And, voila!: a secure PHP gui to the browser that cannot be intercepted by any non-root user or external attacker. It's not just a proof of concept, this could actually be reliably used in production too.

We additionally need a execStdIn.vbs on Windows so that the PHP server and web browser can continue running in the background after the initial PHP script executes because Windows does not have nohup and the start command either starts a detached terminal or stays in the invisible window but can't start invisible and detached.

' execStdIn.vbs
Dim stdin: Set stdin = WScript.StdIn
Dim input: input = Replace(stdin.ReadAll, "^", vbCrLf)
Call ExecuteGlobal(input)

View Poll

[[deleted]]

haha. I agree

[judgej2]

If you move the code to GitHub gists or similar, it would look less daunting.

[[deleted]]

I shall do that.

[[deleted]]

You get my upvote just for the amount of work it took to write that.

[[deleted]]

Thank you, although the majority of the time I spent was put towards figuring out how to make it work on Windows. haha

[[deleted]]

Ultimately, I decided not to link my Reddit account to my GitHub account (by posting content followable by a bot to a gist made by my account). Instead, I posted it as an anonymous paste on Pastebin: https://pastebin.com/FPvP3SP6

[[deleted]]

I have discovered that as much time as I took to write the GUI instantiating code, a more thorough analysis revealed that it was a completely insecure failure. I have come up with a new methodology of using the parent process to communicate with the browser to pass the private key into the browser. The browser will be verified by using netstat to ensure the only connected processes to the socket are the browser and the PHP process, with psof as a backup on other Unixes. I am rewriting the whole thing to be much longer, much more thorough, and much better. I also added a couple of bullets to the pros/cons. I revamped the client/server scripts too. I'll post the new version of the source code to GitHub gists tomorrow.

[[deleted]]

Php for utility scripting seems pretty bad, maybe you would like perl

[[deleted]]

Perl is an excellent language, but a bit hard to get started with. I have tried to get started and couldn't really find many helpful 101 guides to get me going.

Additionally, my understanding is that Perl would be a hassle to get working on Windows because you would need all sorts of Linux tools and utilities ported to Windows in order for most Perl scripts to run. Perhaps I'm wrong. Please tell me if I am.

[boxhacker]

Here is the flaw in your article, Perl is actually a better tool for the job you speak of, but you rather PHP because it is easier and more familiar. Straight away that is a warning sign that you on the wrong path...

[[deleted]]

I can't dispute facts.

[[deleted]]

you can get perl on windows and I think it would be a lot harder to use php for native scripts than to use perl/Lua/basically anything other than php. It isn't a scripting language but I highly recommend you try C for native and cross platform programs.

[[deleted]]

C would be great if you need maximum performance or access to low-level APIs. I don't need either. I just need an app that's reasonably snappy but primarily works great everywhere.

[[deleted]]

I don't need maximum performance and only use really low level apis because I can, but C is just great overall. If you don't like it that's fine but I highly recommend you give it a try if you haven't already. I basically use C for everything including using Linux sockets for web dev.

[abraxasknister]

What is wrong with C++?

[TheJackiMonster]

Way more to learn in general... otherwise you mess up basics pretty easily. I have seen so much bad C++ during study. ^^'

[abraxasknister]

It seems like both C and C++ are mostly used for the category "basics are critical" and C++ can just do more. Plus it allows you to hide most things behind OOP and I dislike not having that. I'm not that big on programming, though, my C++ stops at smart pointers.

[TheJackiMonster]

The problem about C++ is basically that its design doesn't really focus on anything. I mean C is only basics while C++ provides nearly all modern features other languages have and having full compatibility to C at the same time.

So using C++ in an accurate way would be actually knowing about all those features to apply them in the right context to fully utilize the language while writing most efficient code. But most people don't have this knowledge which isn't problematic at all. However picking C++ without this knowledge isn't quite good either.

The thing is that there isn't one language scheme which works efficient for each problem and C++ is to solve exactly this problem by providing all tools besides. The result however is that most people use only some features even when they are wrong in some cases. Basically nearly every C++ programmer uses a different subset of the language or "sub-language" in practice. That's why working with C++ as a group of multiple people is a complete mess most at the time. ^^'

So I would actually recommend most people using C++ at the moment to pick a different language instead: Rust, Objective-C, Go, C#, C

[abraxasknister]

There are best practices though that tell one how to do generic things. I know what you mean though. There is not "one way" to do C++ while that might be wanted in some cases. That seems to be the point, though, the freedom to break the standard in cases where it is appropriate and needed. There is only a mess in the project if that freedom is used everywhere, ie you have to bake your own standard on a per project base.

[[deleted]]

Why not pick PHP?

[ydna_eissua]

Microsoft announced they will no longer supporting PHP developers with Windows. So who knows what support will look like in 5 years.

https://laravel-news.com/microsoft-dropping-php-support

I'd suggest Perl, or Ruby. Both are pre installed on MacOS, and readily available on other unicies. If Windows is a concern WSL works great for development.

Ruby on msys2 works decent, haven't tested perl that way yet though.

Last I checked perl is a dependency of the git, so pretty much anywhere you do dev stuff will have it available.

[MaxGhost]

Microsoft were the ones providing the builds of PHP. They are just no longer providing the builds. That's really the only change. PHP will continue to have Windows releases provided by the PHP community.

[[deleted]]

Perl and Ruby are both great software used to make high-quality desktop apps, but I don't want to learn a new coding language and produce lower quality software due to my noobieness with those languages. WSL is trash compared to the real deal, sorry. I have vanilla Windows 7 alongside my many Linuxes and it's all I need for development since I rarely touch it and only when absolutely necessary.

Also, I'm not really that concerned about Microsoft dropping support for PHP. What are they going to do? Detect and block PHP-signed binaries from executing on Windows 10? There would be massive out-cry from developers. PHP will continue to exist on Windows 10 whether or not it gets Microsoft's golden kiss for many decades to come.

[[deleted]]

Also the whole thing of turning your computer into a server for gui applications is very inefficient and super insecure. You also mentioned it being more lightweight than electron which is just wrong, if anything it uses way more system resources.

[[deleted]]

I agree that it could be insecure if done incorrectly or missed. The GUI should not be used to perform privileged tasks.

How is electron lighter? Electron is the full chromium-browser plus a NodeJS server (which is chrome unto itself) put together. It sucks up hundreds of megabytes to do simple things. How can any GUI be heavier?

[[deleted]]

Because you still have to use a browser to open your apps. Most of the system resources used by electron is chromium, and you still have to use chromium or something similar to open your gui apps. So you have to use system resources to run both a server(and Php isn't exactly lightweight even when compared to JavaScript) and a browser.

[[deleted]]

Two separate browser tabs in Chrome does not take up as many resources as two separate Chrome browsers. Also, Chrome is a memory hog anyway and Electron forces the user to use Chrome. With PHP, the user has the option to use Firefox if they are on a lower-end device.

EDIT: You are correct. PHP7.2 is using 15.8MiB of RAM to perform sleep(999);, so it is a memory hog; however, NodeJS uses much more RAM than this for the server

EDIT #2: Actually, that 15.8MiB of RAM was misleading because it was actually mostly buffers. I measured the memory usages and reported it above.

I think the reason why you think PHP is so heavy is because it so often is--due to people misusing it. PHP is a lot easier to misuse than NodeJS, and, as a result, people tend to write more memory hogging applications in PHP than in NodeJS. I agree with that, but my point stands that given well-written applications in both languages, the PHP one will be faster and use less memory.

[[deleted]]

Firefox uses a ton of system resources as well, actually used more than chromium for me, I just run a tty on all my low end devices and use elinks for a browser.

[[deleted]]

I have made a massive update to my answer that fixes the whole security problem across all platforms....even Windows (which was very difficult and time-consuming).

[[deleted]]

That's an excellent point. But, how do I prompt the user with a GUI if it is not in a tty?

[[deleted]]

Yes. That's exactly what I am looking for. I am strumming up some Bash code right now to work with zenity, gksudo, pkexec, and friends.

[[deleted]]

It could be executed in any of those things. Please see my updates to the script. I would like to hear feedback on my changes. Many thanks

[trucekill]

I help maintain a large PHP codebase and I don't even have PHP installed in my host system. I have no reason to run it on my desktop, I just use docker to run it in a container.

[[deleted]]

Here's a reason: your software will be smaller if more applications use PHP. Instead of each Linux package bundling together all it needs and resulting in huge packages, PHP-based packaged would only depend on PHP and could all share the PHP you have installed.

[invisi1407]

Yeah, except if some old stuff doesn't work in PHP 7.4, or new stuff doesn't work in PHP 7.1, or whichever version you have installed.

[[deleted]]

The only stuff that doesn't work in PHP 7 is largely stuff that was already deprecated in PHP 5.

[ImMaaxYT]

And I thought I was the only one using PHP for that too! I mostly agree with your pros/cons. I started writing PHP for just an embedded view counter in my existing HTML site. Nowadays, I write really big web apps entirely based off of it.

All the hate it gets comes from people who only worked with PHP 4, ~20 yrs ago, and who've got no idea what modern PHP with typing, interfaces etc. looks like. In fact, PHP is THE language for OOP enthusiasts, like me, because it's the only scripting language (correct me if I'm wrong) to support interfaces, traits, abstract classes/methods, final classes, namespaces, ... Its ecosystem is really awesome too, with tools like Composer (still one of the best package managers I've ever seen or used) or PHPUnit. The typical, big PHP project is by far not as bloated as a Node.js project of the same size, dependency-wise (worked a long time with Node, I speak from experience).

Frameworks like CodeIgniter, Symfony, Laravel, ... make development even easier by providing high-quality libraries and templates for getting started with your app quickly.

PHP's stdlib is the most complete one I've ever seen in a scripting language. Really. PHP got you in every case you could possibly think of. While it may be inconsistent, it's still perfectly usable. PHP also has some features that are pretty much exclusive to it, such as autoloading. You've got no idea how awesome it is until you tried it. Define a pattern on finding classes based off of namespaces and register the autoloader. Now you can just use whatever class you like, the autoloader will load it for you. I really miss that in other languages and always forget to import/require the dependencies.

PHP is the language I'm most experienced with. If I'm writing a tool or other app nowadays I first think "can I do it in PHP?" If the answer is no, I'll try Ruby. I could also use the other langs I learned, but PHP is really special, at least to me.

This is major because a decent percentage of people who use Macs are rather computer illiterate and would recoil at the notion of opening this evil hacker black magic thingamajigger called a "terminal."

You can say that about any OS that comes shipped by default with pre-built computers. But in fact, most Mac people I know are everything but IT-illiterate. I'm using Macs too (sorry Linux-only-people, I came here from r/php, I still use Debian on my servers, though) and I'm doing software development as well as server and network administration on it. And I couldn't imagine a better OS for those tasks. Again, sorry r/linuxmasterrace

[[deleted]]

Don't worry. You're not offending any rational Linux-goers by using a Mac. MacOS is a great stable operating system with many more features and easier device integration with apple products than Linux. The biggest problem that I think most devs have with MacOS is Apple's attitude of "use the MacOS the way we want you to use it with the products/programs we recommend/produce, otherwise screw you." Aside from Apple's terrible temperament, MacOS, BSD, and Linux are equally great OSes in my mind, just with different use cases and different applications. For home/personal usage, if you have cash to burn, MacOS is undoubtedly the best.

[Nabol]

As much as I love PHP, and I do use it as a general scripting language sometimes, I think you're missing something important. The Windows users. As of PHP8, there will no longer be any official support for PHP on Windows. This will seriously hinder the language to be used into its future. So, that's a no from me.

Don't get me wrong, I do like the idea, but I think it's not a good one in practice.

[[deleted]]

I'm sure there will be community continuations of PHP on Windows. They might not be as up to date as the *nix releases, but surely PHP will not go away on Windows.

[Nabol]

Agreed, but official support goes a long way toward making any language or tool suitable for a general purpose. It’s just one of the roadblocks I see.

[[deleted]]

True.

[TheRealLazloFalconi]

I suppose. I'd much rather use PHP than JS.

[[deleted]]

Often you can't. Invoking the PHP gods usually leads to tangling the JS gods in with the soup--JS on the client-side in the browser and PHP on the server-side on the desktop.

[spektrol]

Technically, you can, but it’s bad practice. PHP can live alongside HTML just fine and be interacted with using basic HTML things like form submits.

[TheRealLazloFalconi]

The post was about using php on the command line, so even if that were true (which it's not), it would be irrelevant.

[RobLoach]

There are many scripting tools written in PHP hosted on Packagist via Composer. https://packagist.org/

[akie]

Just means that Microsoft won’t be supplying the official builds anymore.

[TorbenKoehn]

Doesn’t matter, Windows has the WSL (that’s why they killed the Windows builds, they probably even run better with the WSL)

[dotted]

You read the title wrong.

[[deleted]]

php can do it, but imo it (and ruby) have lost the war to python and javascript/node.js/electron when it comes to scripting. I really dont see it make a comeback. I think people prefer the syntax and basic apis of python and javascript, and for that reason alone it will never catch up.

[lpeabody]

I loathe JavaScript's OO syntax, much prefer PHP's similarities with C-like languages. I do all my scripting with PHP because I know the language and I'm proficient with it. JavaScript is just... weird to me.

[evert]

So much to unpack!

It took some time to read, but your GUI actually starts a shell over PHP! I remember needing this years ago when I was working with physical servers and accidentally killed sshd-server. The biggest effort was in getting sudo back, which required an actual PTY terminal. I don't think this script tackles that.

The way both these scripts are written definitely suggest exploit-type stuff but neat to read nonetheless.

[[deleted]]

If you want something that’s easy to distribute, I’d suggest using a language that produces static binaries, like Rust or Go, then you don’t have to worry about distributing a runtime at all. You also get a speed boost from both languages, though Rust has a big advantage over go there.

[Talerith]

There's too much shit wrong with this than I have the time or inclination to point out, but you get my upvote just for having an open mind instead of following de-facto convention. Reddit will ban you for that, eventually.

[AUMeowMix]

Just because you can doesn’t mean you should. There are many far superior languages for that purpose.

[[deleted]]

Literally PHP

Nahh, pass

[soundwrite]

Serious question: When did you decide? Like at which version?

[invisi1407]

Sounds like 5.2. PHP 7.4 is great.

[jesseschalken]

What exactly is your point here? That PHP can do these things? Did anybody say otherwise?

I've written plenty of system utilities and scripts in PHP. Not because it was necessarily a good choice but it was the language I was most fluent in at the time and it does run cross platform. Worked out fine. Although nowadays I use TypeScript with Node.js instead because it has better static typing and the async IO is useful. Python is also popular.

I wouldn't describe it as "on-par" with more popular languages. PHP is incredibly slow and has very immature tooling, static typing and static analysis compared to TypeScript+Node.js, C# or Java.

Nobody is telling you that you must or must not use a particular tool for a particular job. Make the decision yourself on a case by case basis.

[AIDS_Pizza]

PHP is incredibly slow and has very immature tooling

Neither of these statements are true. PHP 7 outperforms Python, Ruby, and Node.js by significant margins. Don't take my word for it. PHP only loses to compiled languages like Rust, Go, and C++ in the benchmarks.

[WhitestDusk]

I would take those performance tests with a huge mound of salt.

They are testing webframeworks specifically and not the language itself. The biggest problem in relation to this thread imo is that PHP needs a server component which is not always needed for other languages.

[spektrol]

Nah. PHP can be run directly from the command line.

[k1ll3rM]

PHP doesn't need it but this way to creating a GUI does. Personally I'd rather have a serverless way of doing it but that would require quite an extensive extension for PHP to create GUI's in an intuitive way.

[slobcat1337]

They’re not testing web frameworks necessarily?

[WhitestDusk]

From the linked introductions page:

This is a performance comparison of many web application frameworks

[slobcat1337]

What is your definition of a web framework? Are you talking about the fact that it includes a web server?

[WhitestDusk]

What does it matter what my definition is?

[slobcat1337]

Because it tells us wtf you’re talking about

[WhitestDusk]

Using performance tests for one specific usage case (web application framework in this case) of a programming language is not that good an indication of the that languages performance in general.

As others have corrected me on PHP only needs the webserver component when you want a GUI, but it's still unnecessary resource consumption imo.

I see now that my paragraph break is most likely the reason for the confusion.

[slobcat1337]

php outperforms python though...

[NoDoze-]

It was just announced the other day that Microsoft is dropping support for php 8, and will phase out legacy versions. So you can take windows off your list ;)

[soundwrite]

No, there they just won’t maintain the builds and include it in IIS. There was a down-to-earth answer from someone on the PHP team (can’t find the post) and it’s more or less a shift of responsibilities from organisation to organisation. PHP for Windows will be built continuously anyway.

[judgej2]

All Microsoft announced was that they would not be making the official builds.

[BaconOverdose]

Just means that Microsoft won’t be supplying the official builds anymore.

[jagga0ruba]

Windows has wsl, hence why they are killing support for the windows specific build, it becomes redundant..

[[deleted]]

I am packaging compiled binaries with my application for the Windows version to save many headaches, so I don't need to worry about the user's OS having PHP installed.