Some guy called one of my Snipplr submissions "crap" because I used if ($_SERVER['REQUEST_METHOD'] == 'POST') instead of if ($_POST)
Checking the request method seems more correct to me because that's what I really want to do. Is there some operational difference between the two or is this just a code clarity issue?
Here's what worked best for me when trying to script this (in case anyone else comes across this like I did):
$ pecl -d php_suffix=5.6 install <package>
$ pecl uninstall -r <package>
$ pecl -d php_suffix=7.0 install <package>
$ pecl uninstall -r <package>
$ pecl -d php_suffix=7.1 install <package>
$ pecl uninstall -r <package>
The -d php_suffix=<version> piece allows you to set config values at run time vs pre-setting them with pecl config-set. The uninstall -r bit does not actually uninstall it (from the docs):
vagrant@homestead:~$ pecl help uninstall
pecl uninstall [options] [channel/]<package> ...
Uninstalls one or more PEAR packages. More than one package may be
specified at once. Prefix with channel name to uninstall from a
channel not in your default channel (pecl.php.net)
Options:
...
-r, --register-only
do not remove files, only register the packages as not installed
...
The uninstall line is necessary otherwise installing it will remove any previously installed version, even if it was for a different PHP version (ex: Installing an extension for PHP 7.0 would remove the 5.6 version if the package was still registered as installed).
connection.setRequestProperty("Content-type", "application/x-www-form-urlencoded");
The content type must match the actual format of the postData. A content type of application/x-www-form-urlencoded is only necessary if the content type is actually url encoded. E.g. you're encoding POST data as follows:
String data = "param1=" + URLEncoder.encode(param1, "UTF-8")
+ "¶m2=" + URLEncoder.encode(param2, "UTF-8");
This way the other side will be able to parse the data according the specified format without breaking it.
And,
connection.setRequestProperty("Content-Length", Integer.toString(postData.length));
This is preferable to ensure a robust data transfer. If you omit this and the connection somehow get broken, then the other side will never be able to determine if the content is fully streamed in or not.
That said, the cast to HttpUrlConnection is unnecessary if you know the fact that the request method will "automatically" be set to POST if you do:
connection.setDoOutput(true);
or in your case more suitable:
connection.setDoOutput("POST".equals(method));
Xcopy documentation says the following:
Specifying whether Destination is a file or directory If Destination does not contain an existing directory and does not end with a backslash (), the following message appears:
Does destination specify a file name
or directory name on the target
(F = file, D = directory)?
Press F if you want the file or files to be copied to a file. Press D if you want the file or files to be copied to a directory.
You can suppress this message by using the /i command-line option, which causes xcopy to assume that the destination is a directory if the source is more than one file or a directory.
You need the opposite, but there is no such switch.
The solution is proposed here: https://.com/a/4283533/532647.
It is suggested to prepend the xcopy command with echo f | prefix, which basically does the following: it simulates a user pressing f key when xcopy asks.
So your command should look like:
if exist $(TargetPath)
echo f | xcopy "$(TargetPath)" "C:UsersIncubbusDocumentsVisual Studio 2010My Librariesz.lib" /Y
Operator | just pipes the output of echo f (== f) into xcopy command and it is read when appropriate. More information about output redirection here: http://ss64.com/nt/syntax-redirection.html.
UPDATE: As Govert points out, this hack won't work under a localized version of Windows. However, another hack will work:
xcopy D:file.zip c:renamedFile.zip*
Appending destination file name with an asterisk * makes xcopy not ask whether destination is a file or a directory.
Never used any of those, but they look interesting..
Take a look at Gearman as well.. more overhead in systems like these but you get other cool stuff :) Guess it depends on your needs ..
Well, they don't do the same thing, really.
$_SERVER['REQUEST_METHOD']contains the request method (surprise).$_POSTcontains any post data.It's possible for a POST request to contain no POST data.
I check the request method — I actually never thought about testing the
$_POSTarray. I check the required post fields, though. So an empty post request would give the user a lot of error messages - which makes sense to me.