Quote:
Originally Posted by Katsunami
I've solved things like that ages ago, before languages abstracted that.
In the past I had a file, that had things in it such as:
DIRECTORY_SEPARATOR = /
CURRENCY_SYMBOL = fl.
And so on. I also had language files like that, and in some programming languages, I still work like that if they don't have the required abstraction, or the abstraction is more cumbersome than this method.
In some languages, I just included the file (such as in PHP, including 'constants.php"), while in other languages, I read it as if it was an INI-file.
Not perfect, but things like that did allow me to write a backend on a Windows webserver and then put it onto a Linux one afterward, with just a bit of reconfiguration.
|
I've done analogous things.
One of the things I've had to do a fair bit of is moving stuff between Unix and Windows. Directory separators are one PITA. Differing EOL conventions are another.
In Unix, lines are terminated by a Line Feed character - ASCII 11. In Windows, lines are terminated by a Line Feed
and a Carriage Return - ASCII 13. (And to make life complete, Mac OS "Classic" used only a CR.)
In one case, I had production reports generated on a Unix server that were sent in email to project managers. The reports were standard text files. They showed up as attachments to email in Outlook, and the PMs double clicked the attachment to read them. By default, Windows opened them in Notepad.
Notepad is
stupid, and didn't grok the EOL convention. Because there was no CR at the end of the line along with the LF, you got a stair-step effect, where the next line appeared on a new line, but did not begin at the left margin.
I had to add a function to the script that handled the email to convert line endings to CRLF before sending the reports.
Way back when, I ran a package under MSDOS called the MKS Toolkit. The Toolkit provided MSDOS implementations of all of the Unix commands that made sense in a single-user, single tasking OS like DOS. The killer app for me was a complete version of the Unix Korn shell, with everything save asynchronous background processes.
Installed in fullest Unix compatibility mode, it could be hard to tell you
weren't on a Unix machine when you were in the MKS Korn shell.
But the Toolkit used Unix directory separators and EOL conventions. It mostly worked, but some DOS programs I used got very confused, because they were hard coded to expect \ as a directory path separator and / as an option delimiter, even though there was an MSDOS function that would let you change that at the OS level.
I wound up writing wrapper functions that reset things to the DOS default before running the DOS programs, then set them back to the Toolkit default when the program exited.
I haven't had to do stuff like that in a while, and that makes me happy.
______
Dennis