PHP, with various commandline shenanigans, 0-33
Depending how I read Command-line flags on front ends, various of these answers may apply.
I feel none do, so downvotes are fine and expected on this one :) I'm posting it more as an exploration of the problem-space, perhaps towards an eventual argument that a solution is not possible in PHP, than an answer that I expect to be accepted.
I've given my arguments against them all, summarized with opinionated bold statements, because that naturally makes the arguments more true. I'm very interested to hear counterarguments, or additional arguments, in the comments!
php -r 'echo"Hello, World!";', 0
One interpretation is that nothing on the commandline counts, but that the entire commandline is treated as a kind of "language dialect name" for the entry.
Against: All code should be counted. Otherwise, this approach makes any contest where bytes matter trivial in almost any language, by offloading all work to the CLI. The parameters to the -r flag here are not a "flag to choose a language option", they are "code", and should be counted as such.
PHP -r, 20
php -r 'echo"Hello, World!";'
It could be argued that, while we count the code on the CLI, the sloc requirement only applies to the contents of source files. If there is no source file, then there are no code lines in source files!
Against: All counted code should be passed to sloc. Every language lets you slap code in the cli params. The challenge isn't meant to degrade into "run hello world without using a source file", so this isn't an interesting solution to the challenge.
PHP -r ignoring quotes, 29
php -r '/**/echo "Hello, World!";/**/'
So we can pass in a minimal code sample on the commandline, getting all the benefits of avoiding PHP's <? requirement, without paying any significant penalty.
Against: Necessary escaping of code should count as code. There's no good argument FOR ignoring the quotes. Not-ignoring them makes challenges more interesting anyway.
So I'd argue that all characters which are counted should be passed to sloc, and this solution is wrapped in quotes, and the quotes should be counted. A quoted string counts as a code line in sloc. So, this fails the sloc test.
PHP -r plus shell escapes, 33
php -r/**/echo\"Hello,\ World\!\"\;/**/
Against: This is no longer PHP. We're not, now, really coding in PHP, we're coding in (some shell) + PHP. If this were submitted as a bash script it'd count as 39 characters, and it'd fail the sloc test. We shouldn't get to reduce the count and pretend it passes, just by pretending it's run in one of the utilities the shell called.
PHP with filepath and param ordering, 16.
This one's a two-parter! First, a file called
/x, containing only our 13 character output string:
Call it as:
Then, assuming 1) we count the filename as it is used on the commandline, and 2) we prepend that to the code we pass to sloc, because everything counted is code, sloc interprets it as a one-line comment.
Against: both assumptions above are dumb.
PHP with various failed efforts, inf
Including these just as informational: trying both -r and a file specifier, to address the "depends how we concatenate" problem, above.
filename for comment, then -r for code.
php //x -r 'echo "hi"';
The -r param did not run if a filename preceded it on the line. Same was true of the
Against: Given the -r flag doesn't count, it's hard to see how this woulda been counted. And it doesn't work anyway.
Maybe the BREF group didn't work because they need actual input lines to parse, since they control per-input-line behavior?
echo | php //x -B 'echo "hi"';
Same deal. They don't run if a filename for an empty file precedes them on the line. Same was true of the
Against: This is now (some shell), and it doesn't work.
-w param is "Output source with stripped comments and whitespace." which almost sounds like an exact description of the challenge! Using
php -w x.php, a source file like
... feels like it should work.
Against: A coding challenge requires that the code runs. No actual code was executed, and I feel that's required, to be in the spirit of a coding challenge. More importantly, it doesn't work: without a leading
<?, PHP doesn't see this as PHP code, so does not strip the comments.
Trying variations on this approach, turns out
-w does not work with
-w does run with direct or piped input. However, these have the exact same problem as using a file: PHP requires the leading
What about exploiting ini file params?
php -a -d cli.prompt='"Hello, World!"'
Against: Doesn't run code, doesn't work. Almost works, but also outputs "Interactive mode enabled\n\n".
Exhaustive exploration of PHP-CLI args
Some push unwanted output to stdout that cannot be modified or redirected through config or code, so are unusable:
-a Run interactively.
-i Show info.
--ini list ini files.
-m Module list.
--rf function info.
--rc class info.
--re ext info.
--rz Zend ext info.
--ri ext config info.
-s Prettyprint source.
Some seem to offer no advantage over simpler alternatives:
-B Begin code. No better than -r?
-E Run at end. No better than -r?
-f File. No better than default exec file param?
-F File every line. No better than default exec file param?
-R Run every line. No better than -r?
Some seem irrelevant, affecting neither perception as a comment, nor output:
-c Config path. Irrelevant?
-e Debug info. Irrelevant?
-H Hide args from ps. Irrelevant?
-n No Config. Irrelevant?
-S Webserver. Irrelevant?
-t Docroot. Irrelevant?
This leaves us with just four that look potentially exploitable.
-d Define INI entry, which could include these likely candidates:
auto_prepend_code could help somehow, but not sure how they'd be any better than the
cli.prompt already tried above.
opcache.* could create output then modify code? Feels an invalid solution, though, even if it worked.
filter.default I think only filters input, not output and certainly not code.
output_buffering feels like a VERY likely candidate.
output_handler feels like a VERY likely candidate.
-r Run code. Explored above, no success.
-w Print stripped source. Explored above, no success.
-z zend ext. Would require a zend extension that could help us.