Does PHP self auto-handle path delimiters in Win and *nix?
Ex.: converting \ to / ... or \ to \\?
Thanks.
No. But you can use the DIRECTORY_SEPARATOR constant.
Predefined Constants
Your question is not fully clear to me but... I'd aswer "yes, but". "Yes" as your script can do i.e. include "foo/bar/smth.php"; and it will work the same on windows and linux/unix PHPs and you do not need to bother (however if you do include "foo\bar\smth.php"; then it may work on windows (never checked) but will not work on linux/unix, so beware). So filesystem access layer is aware about this and would take care. And "but", becasue if you are also talking about i.e. doing http access (i.e. over HTTP) then "No" as it got nothing do with PHP. Also, I recall some MSIE did convert backslashes for normal slashes, so crap like htt:\\ works, but that's example of extremely wrong approach.
Related
I know there're plenty of topics regarding escaping characters but I just can't find the solution for my problem.
It's very easy. This is string I have:
$path = "C:\Users\Me\Desktop\14409238.jpg";
Howver, no matter how many escaping techniques I use, I can't manage to display the correct path without destroying it. In all cases the \14 will be replaced with
C:\Users\Me\Desktopd09238.jpg
How do I solve this?
Don't use backslashes in PHP for windows paths. It's smart enough to convert for you:
$path = "c:/users/me/desktop/...";
Using backslashes runs into the exact problem you have - backslashing certain characters turns them into metacharacters, not regular characters.
try to change, the Physical path to access the image, stored on Desktop can be written as,
$path = "C:\Users\Me\Desktop\14409238.jpg";
to
$path = "C:\\Users\\Me\\Desktop\\14409238.jpg";
Avoid the situation entirely, PHP under Windows allows you to submit paths with the backslash
c://Users/Me/Desktop/file.jpg
This also avoids interoperability headaches when a script must run within .nix and Windows.
I am running PHP on an IIS and I am having trouble with magic constants
I wish to use a framework(YII) which has alot of the following:
require(__DIR__ . '\..\vendor\autoload.php');
Problem is that this returns:
G:\PleskVhosts\***.com\api\web/../vendor/autoload.php
Which causes obvious problems
So I was wondering if there was a way to configure PHP so that the magic constants always return with / (To my understanding IIS/Windows accepts both back-slash and forward-slash)
I don't think it matters if you use / or \ in file paths, Windows usually works with both. It won't work with a single backslash though, you need to double backslash it in your code to escape the backslash if that makes sense. Try running...
var_dump(file_exists(__DIR__ . '/../vendor/autoload.php'));
If it returns true then there shouldn't be a problem. Otherwise double check the file path is actually correct. You can also use realpath to translate the /../ into a full path first.
I have this project in php I am working on and I find very annoying to type -> to call methods. I want to make vim do the job for me. I want it to replace [^\s]. (non space + dot) with ->.
Also, I the dollar var prefix annoys me and I wish I could replace \s[a-z_] (white space followed by lower A to Z and underscore) with $ + the next letter I typed.
I.E.
a #=> $a
foo + bar # => $foo + $bar
this #=> $this
this.myMethod() #=> $this->myMethod()
That should happen only in php files, of course.
Is there a way to accomplish that? Something a little fancier than abbreviations maybe.
For the first problem:
inoremap . ->
in your .vimrc would suffice. If you want it specific to php files:
filetype on
autocmd FileType php inoremap . ->
As for the second, I don't really see a way this can be written to work automatically.
I am not sure if this is good idea to handle your source code in this way, since it could destroy your codes, however for your requirement, this line do the two substitution you wanted:
%s/\v(\s|^)\ze[a-z_]/&$/g|%s/\./->/g
at least it works for the example you gave.
Though you can build such "conditional remappings" with :imap <expr>, I highly recommend against doing that.
Your stated rules are still way too simplistic; the first one wouldn't allow you to enter any comments like Just a hack. (would turn into Just a hack->). You'll spend more time (laboriously) tweaking your rules, or undoing / suppressing the automatic conversion, just for saving a single keystroke here and there.
Imagine yourself in another editor, debugger, a colleague's laptop. Now you're dependent on your auto-conversion scheme, and you'll look like a fool!
For me, it looks like you're coming from a different knowledge and still feel the beginner's pain of walking in unknown terrain. Persevere; you'll get over that soon!
Alright, so apparently python 3 is pretty ridiculous when it comes to urllib.
So, I have an url like this formatted like so,
http_request = "http://localhost/system/index.php/index_file/store?cid={0}&cname={1}&fname={2}&fdir='{3}'"\
.format(client_id, client_name, each[1], each[2])
where each[1] and each[2] are the file names and file directories, respectively.
So a generated result of http_request through print() would give something like this,
http://localhost/system/index.php/index_file/store? \
cid=90823&cname=John Smith&fname=Sample Document.doc& \
fdir='C:\Users\williamyang\Desktop\Files\90823 Michelle Moore\Sample Document.doc'
(The purpose of the lone backslash is just so it fits here better. The actual code doesn't have lone backslashes at the end of each line.)
And that was perfectly fine if I enter that URL into a browser. The PHP app recieved all the indices through $_GET, then off to MySQL, no problems.
But if I let python do it,
PHP tells me indices $_GET['fname'] and $_GET['fdir'] Does not exist!!! What madness. Okay, then,
I tried everything from urllib.parse, urllib encoding and decoding, http_request.replace('\\', '/'), and many others.
None of which worked.
I was once told by my prof python does funny things when it comes to character encoding.
here is how I send my URL, before all the crazy and useless urllib parse experiments
def getResponseCode(url):
conn = urllib.request.urlopen((url))
return conn.read()
Where url = http_request
How can I go about solving this?
PHP says $_GET['fname'] and $_GET['fdir'] Does not exist
But when I paste the auto-generated http_request into a browser,
Everything is fine
URLs are not supposed to contain spaces. Your browser will automatically percent-encode URLs, replacing characters that shouldn't be in a URL with something like %20 or +, following the rules of URL escaping. Python won't do this automatically; most likely, the convenience introduces ambiguities that matter for programming, but don't bother the average web user. The Python tools for url escaping are urllib.quote and urllib.quote_plus; you probably want quote_plus. Pass the path component of the URL to urllib.quote_plus before sticking it to the domain name, and you should be good to go.
Solution for python 2:
How can I normalize a URL in python
Solution for python 3:
Ma wonky solution>
right after reading directories from os.walk() do var.replace(" ", "_")
on php end,
$var = str_replace('_', ' ', $_GET['var']);
Whenever I work with PHP (often) I typically work on a Windows box, however I (try to) develop platform agnostic applications; one major point of issue being the use of directory separators.
As many know, doing any filesystem work in a Windows environment in PHP, you can use forward slashes in lieu of backwards, and PHP sorts it out under the hood. This is all fine when it comes to using string literals to pass a path to fopen() or whatever; but when retrieving paths, be it __FILE__ or expanding with realpath(), the paths retrieved are of course using the OS appropriate slashes. Also, I've noticed some inconsistencies in trailing slashes. Once or twice __DIR__ has appended one (a backslash) and realpath() too (I prefer the trailing slash, but not intermittently)
This is clearly a problem for string comparison, because instead of doing:
compare_somehow('path/to/file.php', __DIR__);
For the sake of reliability, I'm having to go:
compare_somehow('path/to/file.php', rtrim(strtr(__DIR__, '\\', '/'), '/') . '/');
This seems like alot of work. I can drop it into a function, sure; now I'm stuck with an arbitrary function dependency in all my OO code.
I understand that PHP isn't perfect, and accommodations need to be made, but surely there must exist some platform agnostic workaround to force filesystem hits to retrieve forward slashed paths, or at least a non-intrusive way to introduce a class-independent function for this purpose.
Summary question(s):
Is there some magical (though reliable) workaround, hack, or otherwise to force PHP to kick back forward slashed filesystem paths, regardless of the server OS?
I'm going to assume the answer is no to the above, so moving on; what provisions can I make to enforce forward slash (or whatever choice, really) as the directory separator? I'm assuming through the aforementioned filter function, but now where should it go?
Forward slash for everything. Even if the host OS separator is #*&#.
As I commented I can't really see why you would have to do this (I'd be interested in a quick description of the specific problem you are solving), but here is a possible solution using the output of __FILE__ as an example:-
$path = str_replace('\\', '/', __FILE__);
See it working
This will(should?) work regardless of the *slashes returned by the OS (I think).
Unfortunately I'm not aware of "some magical (though reliable) workaround, hack, or otherwise to force PHP to kick back forward slashed filesystem paths, regardless of the server OS" other than this. I imagine it could be wrapped in a helper class, but that still gives you an arbitary dependancy in your code.