So, I'm a beginner trying to learn django right now with "Practical Django Projects" with windows in eclipse pydev.
Anyways, main issue is I use windows and it seems to suggest I should use front slash in the comments for settings.py. But by default, the databases is already set to:
'NAME': 'C:\\Users\\dtc\\Documents\\Eclipse\\cms\\sqlite.db'
And while I was going through the book, it wants me to add this:
url(r'^tiny_mce/(?P<path>.*)$', 'django.views.static.serve',
{ 'document_root': '/path/to/tiny_mce/' }),
But that path didn't work until I changed to double backslash \\path\\to\\...so I'm thinking I should just not worry about using double backslash.
It would be great if someone gave me a little insight on this because it's giving me a total headache while trying to learn django.
Use python to get current directory and call a join on it with whatever you need to add. This will make it cross platform as python will take care of converting backslashes and forward slashes for you.
import os
CURRENT_DIR = os.path.dirname(__file__)
TEMPLATE_DIRS = (
os.path.join(CURRENT_DIR, 'templates')
)
That will save you on typing and the path will be correct. If you look in settings.py that django generates it will tell you to always use / even on Windows.
# Put strings here, like "/home/html/django_templates" or "C:/www/django/templates".
# Always use forward slashes, even on Windows.
# Don't forget to use absolute paths, not relative paths.
One last thing, your urls should use forward slashes because that is how django is going to use them.
Hope that helps
Related
As soon as I try to access a folder/file containing an emoji in its name from my Lua 5.2 script, for example like this:
os.execute('start "" "' .. path .. "\\scripts\\menu\\📄 My Scripts" .. '"')
The Windows' Command Prompt simply refuses to open it with the following error message:
I'm aware Windows' Command Prompt doesn't support emojis and therefore is not possible to make it work just like that, but my doubt is if won't exist some workaround or whatever I can do to ensure any Windows/Unix user is going to able to get the folder open by my Lua script without any problem.
I have tried i.e. things like use the codes instead (1246 and U+1F4F0 in this page facing up case) without success. Couldn't I for example simply use some kind of "wildcard" instead? I mean, knowing it's always going to be the very first character in the name. Or, well, any other ideas will be welcomed, cause nothing I'm trying really seems to work...
Of course if it's going to represent any problem I'll simply refuse to use them, but it came in handy for some "first sight" folder distinction and, if possible, I'd like to can count this little visual resource 🙄
This is a Problem about how the string is constructed.
I found only one solution with [[command "path"]] (on Windows 11 and Lua 5.3)...
os.execute([[start ]] .. path .. [["\scripts\menu\📄 My Scripts"]])
-- My Testpath is/was: os.execute([[dir "%localappdata%\nvim\📄 Lua"]])
...the long string ([[]]) will not be interpreted (coercionated) by Lua.
That also have the side effect that you can use single backslashs with that kind of string.
Environment variable expansion (e.g. Windows: %localappdata%) only works inside doublequotes.
Single quotes instead ([[command '%localappdate%\path\']]) will not work (expanded).
os.execute accepts only ANSI-encoded strings (win-1252 in European Windows), but it is unable to encode an emoji.
Hint: you can create .bat-file to do the task for you and invoke it from Lua with os.execute.
I am trying this in Windows 8.1, with python v.3.4. The os.path module has a join method which, according to the documentation, is a safe way to join fragments of files or folders without mixing up back and forward slashes. In the code snippet below I am trying to join a file and a folder:-
>>> photo = r"\camera\picnic.jpg"
>>> folder = os.getcwd()
>>> print(folder)
C:\Users\Renae
>>> path = os.path.join(folder, photo)
>>> print(path)
C:\camera\picnic.jpg
And boom goes the dynamite. I was expecting path to be C:\Users\Renae\camera\picnic.jpg. I've tried removing the r in front of photo with no results. I've also tried backslashes even though Windows uses forward slashes which made it worse. The result was a mix of back and forward slashes. If I remember correctly this was not a problem in Linux.
Try removing the initial slash.
I can't speak for windows because it's been a long time since working on windows, but in *nix systems, starting a path with a slash signifies the root of the file system. I'm guessing that the implementation in python (and possibly more languages) use this convention on windows as well. I don't have a windows box to verify this on though.
Did a MediaWiki upgrade from 1.15.1 to 1.20.2 by following the simple update instructions (basically a new installation, copying over the old LocalSettings.php, update script and copying over images). Weird thing now is that all of the File: prefixes don't work. Instead the internal links to images is a "file:name of image" URL rather than "http://mediawiki address/index.php/File:name of image".
Anybody else getting this. Assuming it is something wrong with the old LocalSettings.php.
Ran the refreshLinks and refreshImageMetadata maintenance scripts without fixing the problem.
In the comments, you wrote that you have file: added to $wgUrlProtocols. This is very likely what's triggering the problem.
It looks like something has changed in the parser between MW 1.15 and 1.20 so that it's now parsing file:whatever as an external link (since it matches the file: prefix you've defined in $wgUrlProtocols) even if it's inside square brackets.
The obvious workaround would be to change the $wgUrlProtocols entry from file: to file:// so that it will only match if the slashes are there (as they should be, according to standard file: URL syntax). Since your on-wiki filenames are, presumably, very unlikely to begin with double slashes, they should not match this more specific prefix.
That said, this could still be considered a bug in MediaWiki. You may want to file a bug report about it, if there isn't one yet.
(Edit: Looks like Mark A. Hershberger filed one already.)
I want to create a url like www.facebook.com/username just like Facebook does it. Can we use mod_rewrite to do it. Username is name of the user in a table. It is not a sub directory. Please advise.
Sure, mod_rewrite can do that. Here is a tutorial on it.
Yes you can do this but you might have a couple of initial hurdles to get it going correctly.
The first is that you will have to use a regular expression to match it. If you don't know regex then this can be confusing at first.
The second is that you will need to take into account that of you are going to rewrite the top path on the domain you will have to have some mechanism for only rewriting if the file doesn't exist.
I guess if mod_rewrite supports testing if the url points at a real file that will be easy. If not you might have to use a blacklist of words that it wont rewrite as you will need to have some reserved words.
This would include at the least the folder that contains your images, css, js, etc and the index.php your site runs off, plus any other php files you have kicking around.
I would like to be more help but I am a .net guy and I usually help out in asp.net url rewriting issues with libraries such as UrlRewriter.net which have different configurations than mod_rewrite.
To match the username I would use a regex like this:
^/(\w*)/?$
this would then put the bit in the brackets into a variable you can use in the rewrite like
/index.php?profileName={0}
The regex I provided means:
^ nothing before this
/ forward slash
(\w*) any number of letters or numbers
/? optional forward slash
$ nothing after this
If I wanted to create a string which is guaranteed not to represent a filename, I could put one of the following characters in it on Windows:
\ / : * ? | < >
e.g.
this-is-a-filename.png
?this-is-not.png
Is there any way to identify a string as 'not possibly a file' on Linux?
There are almost no restrictions - apart from '/' and '\0', you're allowed to use anything. However, some people think it's not a good idea to allow this much flexibility.
An empty string is the only truly invalid path name on Linux, which may work for you if you need only one invalid name. You could also use a string like "///foo", which would not be a canonical path name, although it could refer to a file ("/foo"). Another possibility would be something like "/dev/null/foo", since /dev/null has a POSIX-defined non-directory meaning. If you only need strings that could not refer to a regular file you could use "/" or ".", since those are always directories.
Technically it's not invalid but files with dash(-) at the beginning of their name will put you in a lot of troubles. It's because it has conflicts with command arguments.
I personally find that a lot of the time the problem is not Linux but the applications one is using on Linux.
Take for example Amarok. Recently I noticed that certain artists I had copied from my Windows machine where not appearing in the library. I check and confirmed that the files were there and then I noticed that certain characters in the folder names (Named for the artist) were represented with a weird-looking square rather than an actual character.
In a shell terminal the filenames look even stranger: /Music/Albums/Einst$'\374'rzende\ Neubauten is an example of how strange.
While these files were definitely there, Amarok could not see them for some reason. I was able to use some shell trickery to rename them to sane versions which I could then re-name with ASCII-only characters using Musicbrainz Picard. Unfortunately, Picard was also unable to open the files until I renamed them, hence the need for a shell script.
Overall this a a tricky area and it seems to get very thorny if you are trying to synchronise a music collection between Windows and Linux wherein certain folder or file names contain funky characters.
The safest thing to do is stick to ASCII-only filenames.