Is using the directory separator constant necessary? - language-agnostic

I am using PHP, but I guess this question might be language agnostic.
With PHP, a constant is defined by PHP, called DIRECTORY_SEPARATOR. I have seen this in Joomla
define('DS', DIRECTORY_SEPARATOR);
I thought this looked like a good idea so I incorporated it into some of my sites. Now I'm asking myself why. I have only experience on Windows and OS X and from what I know Microsoft, Linux and Apple all use the forward slash as the directory separator.
Is using this constant unnecessary?

As far as PHP is concerned, you might not need it when constructing a path, but it is important for anything you get from the OS.
From http://alanhogan.com/tips/php/directory-separator-not-necessary:
In attempting to write cross-platform, portable PHP code, I used PHP’s DIRECTORY_SEPARATOR constant to write path strings, e.g. "..".DIRECTORY_SEPARATOR."foo", because the “proper” way to do it on Windows would be "..\foo" while on everything else (Linux, UNIX, Mac OS X) it would be "../foo".
Well, as Christian on php.net pointed out and the guys at Web Design Forums confirmed, that’s completely unnecessary. As long as you use the forward slash, “/”, you’ll be OK. Windows doesn’t mind it, and it’s best for *nix operating systems.
(Note that DIRECTORY_SEPARATOR is still useful for things like explode-ing a path that the system gave you. Thanks to Shadowfiend for pointing this out.)

Mac OS Classic uses ":", for instance. See Wikipedia for details. Also it's considered good style avoiding 'magic numbers' or similar constructs.

Windows actually uses a backslash as the directory separator, although some environments that have Windows versions will translate between forward slashes and backslashes automatically (Python comes to mind).

I learned that the best way to write cross-platform compatible code is to never use DIRECTORY_SEPARATOR, or backslashes \\, and to ONLY use forward slashes /.
Why? Because a backslash directory separator ONLY works on Windows. And forward slashes works on Linux, Windows, Mac altogether.
Using the constant DIRECTORY_SEPARATOR or escaping your backslashes \\ can become messy. Look at this example:
$file = 'path' . DIRECTORY_SEPARATOR . 'to' . DIRECTORY_SEPARATOR . 'file';
$file = str_replace('/', DIRECTORY_SEPARATOR, 'path/to/file';
$file = (strtoupper(substr(PHP_OS, 0, 3)) === 'WIN') ? 'path\\to\\file' : 'path/to/file';
When you can just do this:
$file = 'path/to/file';
The only downside I came across is that PHP will return backslashes on Windows for all file references from functions like realpath(), glob(), and magic constants like __FILE__ and __DIR__. So you might need to str_replace() them into forward slashes to keep it consistant.
$dir = str_replace('\\', '/', realpath('../'));
I am hoping that PHP in the future will introduce some php.ini setting to always return forward slashes.

Related

What's the difference between these JSON Perl modules?

What's the difference between the Perl JSON modules below?
I have come across JSON::PP and JSON::XS. The documentation of JSON::PP says it is compatible with JSON::XS. What does that mean?
I am not sure what the difference between them are, let alone which of them to use. Can someone clarify?
Perl modules sometimes have different implementations. The ::PP suffix is for the Pure Perl implementation (i.e. for portability), the ::XS suffix is for the C-based implementation (i.e. for speed), and JSON is just the top-level module itself (i.e. the one you actually use).
As noted by #Quentin, this site has a good description of them. To quote:
JSON
JSON.pm is a wrapper around JSON::PP and JSON::XS - it also does a bunch of moderately crazy things for compatibility reasons, including extra shim code for very old perls [...]
JSON::PP
This is the standard pure perl implementation, and if you're not performance dependent, there's nothing wrong with using it directly [...]
JSON::XS
Ridiculously fast JSON implementation in C. Absolutely wonderful [...]
As you can see, just installing the top-level JSON module should do it for you. The part about compatibility just means that they both do the same thing, i.e. you should get the same output from both.
I installed the Perl JSON module a few years ago on a RHEL server I managed and it was a really straightforward process: just install (or build) the module from the CPAN site and you're done.
Installing should be a simple case of either using the OS package manager (if in GNU/Linux), using the cpan utility, or building from source. The OS package manager is recommended, as it helps keep things updated automatically.
To verify that it's installed, just try the following command from the terminal (assuming GNU/Linux):
$ perl -e 'use JSON;'
If it doesn't complain, then you should be good to go. If you get errors, then you should get ready to go in an adventure.
You can install JSON module, cpan install JSON
use JSON;
my $result = from_json($json);
if($result->{field})
{
# YOUR CODE
};

OpenLDAP #SUFFIX# notation

I've started researching LDAP and started following a tutorial to at least start familiarizing with it. While doing that, I noticed that there is an odd (for me) notation in the /usr/share/slapd/slapd.conf file on my computer, namely #SUFFIX# and other things surrounding by the at sign. I think that this is supposed to be interpreted as some kind of a variable or substitution point, but any search on Google turned out nothing, as they ignore special characters.
How should I interpret this and where can I change it?
Sounds like you're talking about the slapd.conf template from the Debian package. #SUFFIX# and the other tokens in that file are replaced at configure time by the maintainer scripts.
(The package also contains a similar template for dynamic configuration; slapd.conf is no longer used.)

Use character # in URL inside file name

I need to put a link with this href="file://attachments/aaaa_#_aaaa.msg"
Obviously in that way is not working because the hash character # is used for anchors.
So I try to change this to: href="file://attachments/aaaa_%23_aaaa.msg"
but when I open the url in the IE, the browser is trying to open this: href="file://attachments/aaaa_%2523_aaaa.msg"
IE is encoding the % character to %25
How can I put the file name in the URL to encode and read the hash character # in all the browsers to download the file?
I can't change the file name to remove this character, so I need a way to deal with this problem.
You will avoid lots and lots and lots of pain if you are able to rename your files so they don't contain a "#" character. As long as they do, you will probably have current and future cross-browser issues, confusion on behalf of future developers working on your code (or confusion on your behalf in the future, when you've forgotten the ins and outs of the encoding), etc. Also, some Unix/Linux systems don't allow "#" in filenames. Not sure what OS you're using, but your filenames should be as portable as possible across OSs, even if you're "sure" right now that you'll never be running on one of those systems.

What characters will comprise a carriage return in an html textarea?

For example on my PC it looks like it will use "\r\n"? Could it ever be something different than that?
Historically it's \r\n on Windows, \r on Mac and \n on *nix. If you take these into consideration you 're golden.
Also: I don't know if this is relevant in your case, but typically many programming languages define a string constant which represents the "native" form of end-of-line for the system they are running on (e.g. PHP_EOL in PHP, Environtment.Newline in C#, etc).
It depends upon the OS I guess, the same old story:
\n for unix like (and I think OS X too)
\r\n for windows like
\r old Apple OSes

Find and Replace in Files - UTF8

Searching for a free application for commercial usage that allows find/replace in multiple files (regular expressions are nice but not a must), that supports opening and saving in UTF-8.
Tried a few like BKReplaceEm but the application ends up saving all the files as ASCII which causes some problems with web-rendering.
Please advise.
[UPDATE] To further clarify, I am searching for a windows utility.
[UPDATE #2] This is going to be used to run through our 450 page site and replace all french characters with the much needed HTML entities.
Notepad++ supports this feature, and is a great little editor in it's own regard.
Edit : Actually, Notepad++ does support replace in files. Click Search -> Find in Files, then select "Replace in files" in the dialog.
In the spirit of previous answer, you can use Perl (which has seamless native Unicode support and whose RegEx capablity are unparalleled). There are Windows perl versions avialable (ActivePerl, Strawberry, or you can use CygWin), and you can even slap GUIs on top of it -= for the latter, you can see what answers are given to my very recent So question :)
Plus, Perl can grab pretty much unlimitedly powerful collection of files, by using globs for simple things, File::Find for more complicated, and using grep on resulting file list to refine further if you need more fancy stuff, e.g. by content of modification time.
UPDATE For a Windows Editor, you can use UltraEdit. It has free evaluation period, and to be perfectly honest, I find the purchase price to be WELL worth paying for this very nice and powerful editor. Among its other features, it supports Unicode, and has pretty fancy search/replace ablities, including Perl RegEx support and S/R in multiple files.
Use sed.
jEdit has a feature called "HyperSearch" (just open the find dialog). You can specify a directory, a file name pattern and jEdit (being based on Java) does support lots of different encodings (and is often smart enough to figure out the correct one).
You could try my editor, Code Trowel
If it doesn't do what you want I'd probably fix it :-)
For windows, Notepad++ is awesome. It's licensed under the GPL. It does search and replace in files and does support regular expressions.