In fact, it seems to start both from the current page path.
Its a subtle one which is only relevant if multiple search paths exist (like for executables, see $PATH).
For example, you can start a local executable with ./filename, but not with filename, as the latter makes (most?) shells search in the paths specified by $PATH and not the current working directory.
In a context of URLs, there is no real difference. One should note though, that relative paths are a common attack vector on web applications (escaping the DocumentRoot using ../).
For directories one would imagine nothing. The PATH variable would not come into the picture as a directory is not a command the shell needs to search.
On the side note here is an interesting page to know more about "./" : http://www.linfo.org/dot_slash.html
Related
What is the difference between these two pathnames? Is / necessary to put in start for going in a folder?
assets/myImg.png
/assets/myImg.png
/assets/myImg.png is an absolute path. It means no matter where do you call the path from it's always the same. assets/myImg.png is relative path to your current directory
You haven't mentioned an OS, so given the leading / I'll assume we're on a Unix-like system.
/assets/myImg.png
This is an absolute path. It's going to look in the root directory of your file system for a folder called assets and go from there.
assets/myImg.png
This is a relative path. It's going to look in the current working directory, which is likely the directory where you started your current program. If you're using this from the command line, it's going to look starting from the current directory of the shell (i.e. the thing you change with cd).
Good morning,
does anyone know how I could configure MAMP (or WAMP) in order to automatically change my project URLs, to localhost without having to search/replace inside my documents (operation I suppose to be a bit gross because possibly altering my code).
My goal is to develop on local while keeping the final and real URLs in my documents.I suppose lot of you have encountered this issue one day :)
In other word, I would like to alternate between online and local more easily.
I a beginner, please consider,
for all the biginners, here's the thing. I've created a config.php file which contains constants: one config file for the local project folder and one for the online server folder.
Inside this config file, I've create a constant (constant are then available everywhere in the project) to define the main URL of the project. e.g.:
define('CST_MAIN_URL',http://www.myproject.com); // for the online config.php file
define('CST_MAIN_URL',http://localhost:8888); // for the local config.php file
Thus, each header or redirection can work with that constant, like:
header('location:' . CST_MAIN_URL . 'index.php');
Then, things must have to do with RewriteEngine in your htaccess file, for instance whenever you must modify the behavior of MAMP/WAMP if an interrogation point or a slash provokes you with its malicious resistance. But, unfortunately RegEx expression must be understood as a basic level for mastering those url rewritings.
Hope it'll helps.
I need to store Houdini *.hda files on a network share.
This folder needs to be sourced by all users.
Usually, for those kind of requests, I use an environment variable in ~/houdini17.0/houdini.env like for exemple:
HOUDINI_TEMP_DIR="/my/custom/temp/path"
But the issue is that I can find a solution for hda/otls files.
Adding it to HOUDINI_PATH="${HOUDINI_PATH};/my/custom/hda/path" or HOUDINI_OTLSCAN_PATH doesn't work and worst, it seems to break other links since a few other houdini nodes aren't available anymore.
Can someone point me to the right environnement variables?
Try using $HSITE and/or $JOB environment variables. Houdini will scan sub folders of the paths defined by $HSITE and $JOB for all relevant files and folders so you don't need to set a bunch of different env vars. You can mirror the folder structure found in C:\Users\username\Documents\houdini16.5
Obviously replace the Houdini version with yours. Also note that $HSITE needs to point the the folder that contains the houdini16.5 folder not the folder itself. This way you can support multiple houdini versions with a single env var.
http://www.sidefx.com/docs/houdini/basics/config.html
For example if $HSITE= //myNetworkShare/Houdini
You would need this folder structure:
//myNetworkShare/Houdini
/Houdini16.5
/otls
/scripts
/python2.7libs
/.....
Note you can only give $HSITE a single path.
I can use:
#+INCLUDE:
to include an org file in another org file, which allows me to assemble, say, a website from various org files. I'm exporting from the C-c C-e exporter in org-mode 7.5.
I could maintain a quite complex publication this way. This modular approach is quite common in, e.g. LaTeX and Texinfo publications.
However, links to images no longer work from the #+INCLUDEd org files. What seems to be happening is that the path to the images is taken as being from the org file that I am exporting from, rather than the actual org file that references the image.
The only ways I can see to resolve this are to:
use a flat file structure; or
make the image path from the referencing file (which I might not know in advance) rather than itself.
Neither of these is really sustainable.
How do I tell org to use the correct image path from its own relevant org file rather than the parent org file?
From what I know of the exporter, INCLUDE files are inserted into the document before export. Therefore the content is part of the document before it starts following paths to reach any links to files (images).
After a bit of testing you likely will need to use absolute file paths. Since you move between Windows and Linux your best bet would be to use a consistent scheme on both starting from your home directory.
Like that you can make the Org link:
[[~/path/to/image.jpg]], which will work on both systems (assuming you have set %HOME% on Windows).
Option 1 is potentially an alternative (although I agree it wouldn't be ideal at all), whereas the second option would have obvious pitfalls if you INCLUDE the file in more than one future document.
I'm familiar with tools like Deadweight for finding CSS not in use in your Rails app, but does anything exist for images? I'm sitting in a project with a massive directory of assets from working with a variety of designers and I'm trying to trim the fat in this project. It's especially a pain when moving assets to our CDN.
Any thoughts?
It depends greatly on the code using the images. It's always possible that a filename is computed (by concatenating two values or string substitution etc) so a simply grepping by filename isn't necessarily enough.
You could try running wget (probably already installed if you've got a linux machine, otherwise http://users.ugent.be/~bpuype/wget/ ) to mirror your whole site. Do this on the same machine or network if you can, it'll crawl your whole site and grab all the images
# mirror mysite.com accepting only jpg, png and gif files
wget -A jpg,png,gif --mirror www.mysite.com
Once you've done that, you're going to have a second copy of your site's hierarchy containing any images that are actively linked to by any page reachable by crawling your site. You can then backup your source image directory, and replace it with wget's copy. Next, monitor your log files for 404's pertaining to gif/jpg/png files. Hope that helps.
Finding unsed images should be easier than CSS.
Just find *.jpg *.png *gif with glob, put those filenames to dictionary or array and find those filenames againt html, css, js files, remove filename if found and you will get unused list, and move those images to another folder with same directory structure (It will be good for restoring for just in case)
Basically like this, and of course for the file names that encrypted/encoded/obcuscated will not work.
require "fileutils"
img=Dir.glob("**/*.jpg")+Dir.glob("**/*.png")+Dir.glob("**/*.gif")
data=Dir.glob("**/*.htm*")+Dir.glob("**/*.css")+Dir.glob("**/*.js")
puts img.length.to_s+" images found & "+data.length.to_s+" files found to search against"
content=""
data.each do |f|
content+=File.open(f, 'r').read
end
img.each do |m|
if not content=~ Regexp.new("\\b"+File.basename(m)+"\\b")
FileUtils.mkdir_p "../unused/"+File.dirname(m)
FileUtils.mv m,"../unused/"+m
puts "Image "+m+" moved to ../unused/"+File.dirname(m)+" folder"
end
end
PS: I used fileutils, because normal makedirs and mv are not works in my windows version of ruby
And I am not good at ruby, so please double check it before you use it.
Here is the sample results I ran in root folder of sample rails folder in my windows
---\ruby>ruby img_coverage.rb
5 images found & 12 files found to search against
Image depot/public/images/test.jpg moved to ../unused/depot/public/images folder
If your image URLs often come from many computed / concatenated strings and other stuff hard to track programmatically within your source code, and your application is in heavy use, you could try a soft "honeypot" approach like this:
Move all the assets to a different directory, e.g. /attic
Set up an empty /images directory (or what your asset directory is called)
Set up a .htaccess file (if you're on Apache of course) that, using the -f flag, redirects all requests to nonexistent image files to a script
The script copies the requested file from the /attic into the /images directory and displays it
The next request to that image will go directly to the image, because it exists now
After some time and sufficient usage, all needed images should have been copied to the assets directory.
It's a "soft" approach of course because a dialog / situation could have not been opened/entered/used by any user during that time (things like error message icons for example). But it will recognize all used files, no matter where they're requested from, and might help sort out much of the unneeded files.
If your file manager supports it, try sorting your images directory by the files' "last accessed" date. Files that haven't been accessed in a long time most likely aren't used any longer.
Along the same lines, you can also filter or grep through your web server's logs and make a list of the image files that it has served up in the last several months. Any images not in this list are likely unused.