I'd like to get my .ackrc configured so ack doesn't look inside my test/coverage folder. So far I've ended up with this :
--ignore-dir=coverage
This works, but it doesn't feel quite as right as :
--ignore-dir=test/coverage
Problem is the latter doesn't work and test/coverage content is searched.
Am I missing something or is ack not prepared to deal with subdirectories ?
The ack changelog explicity mentions this as a feature, supported since ack 1.93_02.
Quote: "The --ignore-dir option now can ignore entire paths relative to your current directory."
I tried it and it works. I would check if your test/coverage directory is directly relative to the folder you're running ack from. Otherwise I'm not sure what could be going on.
Related
In my atom when I add a project, it does not display all content (I mean files and folders)) into it.
F.x. on screen below http folder is full of files/folders.
What could be a reason of that?
I've Mac + Atom 1.0.15 (but it started from very long time ago).
I've had the same issue recently. With one of the new versions of Atom, a setting was enabled that I had never changed, causing some files to not show up any more.
The setting is Hide VCS Ignored Files, which can be found in the Packages / Tree View settings:
Make sure this setting is disabled (i.e. unchecked). When it is checked, it will not show files that are ignored by Git. I noticed a .gitignore file in your first screenshot - that could be causing it.
The setting one above this (Hide Ignored Names) could also be relevant, but I'm not entirely sure what it does.
Anyway, the Hide VCS Ignored Files was enabled in one of my workspaces for some reason, and it caused a similar issue as you described. It's probably worth a try...
i am currently hosting my site on justhost (just as a test server), when i save my work on my local computer through aptana the files are automatically uploaded to the hosting server, and they appear fine. However this only works for my actual files like .php and .html
They do not work for my .css files, so if i save them and upload them the changes do not take effect, until like the next day, or if i turn my computer on and off and leave it a couple of hours, i am not sure why they are not taking effect immediately like the rest of the fiels.
I have tried deleting my cache and adding ?ver=1.0 to the end of the file name, but still no luck.
Also, i checked the hosting directly and the css file has updated to the correct version, but just does not show in browser.
Any ideas on what could be wrong, it would make life much easier if i could get them updating like the other files.
Thanks
I can't be sure what is causing this, but if I'm correct - the files do upload, its not a case of not uploading. It's one of these things
The Cache is holding it (already cleared it though?)
The file is doing some odd cross server transfer, depends what sort of hosting your on, but it may be the file is getting held up somewhere
Try clearing the DNS Cache
Start > type CMD > in the dialog type:
ipconfig /flushdns
That may force the computer to reload the file.
As for an ongoing solution to prevent it in the future I'm out...
I know it has been a while, but as others may find this question the way I did, the solution for me was to enable Cloudflare Developer Mode. Cloudflare was keeping the css files in cache and it drove me crazy to find the solution in another forum. I hope your case may be the same as mine as thus you can solve it as well.
I've revised (but not changed) this question for brevity; see edits for previous version(s)
I have an ASP.net website (non-application, non-MVC) with the following (proposed) file system hierarchy:
What configuration changes (if any) can be made to implement this scheme? Is this possible? I've received the error Cannot use a leading .. to exit above the top when having targeted /Site as the application. I'm wondering if there's a way around this.
As I see it, given the site runs in C:\www\SiteRoot\ at http://example.com/:
PATH URL
~ C:\www\SiteRoot\ none
/ C:\www\SiteRoot\Site\ http://example.com/
~/Site C:\www\SiteRoot\Site\ http://example.com/
/About C:\www\SiteRoot\Site\About http://example.com/About/
Therefore, MasterPageFile="~/Site/About.master" will still resolve correctly,
as will <img src="/About/ImageInAboutFolder.jpg" />. Hopefully this sort of configuration is possible.
If I understand your question correctly, no, you can't.
I've got a Android .apk file that I want to distribute to a few 1000 devices but I don't want to put on the market, therefore I've decided to serve it via a CDN.
However the file I'm receiving via the CDN has been corrupted somehow. It doesn't seem to have merely been truncated, at least the bytes that I've examined in a hex dump are all different.
For what it's worth I'm setting the mime type to be 'application/vnd.android.package-archive', I think my problem might well be related to this.
It's suspicious to me that the file is close to 7/8th the original size - 1155060 vs 1321106 bytes. This makes me wonder if the file is getting treated as 7 bit ascii somewhere along the way...
Aha, I've just realised that the file from the CDN is actually a gzipped version of the original.
I think I'm on the right track in thinking that the mime type is confusing the CDN & it's defaulting to gzipping the file.
I'm guessing the 7/8th file size difference is probably just a coincidence.
Edit:
Yes, this was it, a bodgy fix was to set the mime type to application/zip, which presumably doesn't confuse the CDN (I've got a custom updater so I can get around the fact that mime type is wrong).
How to rename drupal's admin directory as I already have a directory named "admin"?
As Bleadedu pointed out, Drupal has no "directories" in its URL.
The urls you see are all so called "clean urls", achieved with a nifty trick in Apache (the webserver)
configuration. You could disable clean urls that will fix your problem, but may not be an option, if you rely on this feature for some reason.
Another option is to use path module to circumvent this issue. This has downsides too, most notably, the fact you need to manually change each url with admin in it.
The last option is to change the rewrite rules in Apache. This is hard to achieve and requires some knowledge of mod_rewrite.
you can't. simply because admin directory doesn't exist. it's just a url path (defined in all modules that have got a reference of it in hook_menu)
The only solution I have right now is to implements hook_menu_alter and redirect all menus that starts with admin/ somewhere else, but I can't say that it will work 100%.
Instead of changing the path of /admin, you should beef up security elsewhere.
First, finding out your site uses Drupal is a piece of cake.
Huge companies use Drupal, and don't change their /admin path.
Don't use User 1. Most of the time, there is no need for anyone to be using User 1. Even the highest of admins should be given a role, and certain permissions. User 1 should have a complicated long password, changed every (x) number of days or hours, but never actually used. I think there is also a module for this, but I can't remember off the top of my head because I just do this programmatically.
logintoboggan.module
The Login Toboggan module will display the login form for Access denied pages
login_security.module
protect_critical_users.module
userprotect.module
session_limit.module
nodeaccess.module
Don't let direct access to update.php and cron.php. Create a cronjob to run via shell.
-have them direct to forbidden/or a 404 with a search page
Use the tools in cpanel/whm or similar. Knock out bad login attempts and such.
There are a ton of other ways to beef up security in drupal.
I somehow forgot that you said "as I already have a directory named "admin". opps.
I think you would be wise to either alter that other directly instead, put it inside of another directory, or simply don't use it.
It is just going to be very messy. You would have to look into every single module to see if it needs adjusting.
Off the top of my head, the user.module will need to be altered, and also take a look at http://api.drupal.org/api/search/6/url_rewrite.
custom_url_rewrite_outbound and custom_url_rewrite_inbound will work, BUT you will still be able to access /admin by typing it in manually. You will get a forbidden if you stick a "admin" folder in your root.
All in all, I think it would be a messy venture, and you might get a lot of broken updates. Until something like this is offered in core, I wouldn't do it. Even if there was a module that could, I wouldn't use it.
*You will have to "Hack Core," and I don't think this justifies hacking the core.