So, to better explain what I'm asking for, I am writing a zsh plugin for quickly navigating up directories and I want to offer the ability to traverse into a directory by specifying a starting directory in $PWD.
For example, if I am in a directory ~/example/first/left/second and I wanted to go to a directory ~/example/first/right, I could call $ up first/right. I managed to get the functionality working just fine, but I want to offer tab completions in the same way cd ..[/..]* does.
At the moment, here is what I have
_up() {
local -a args
args=(`echo ${PWD#/} | sed 's/\// /g'`)
_arguments ':paths:($args[#])'
}
And so I currently have tab completions working for all of the initial options available, but past that point I have no idea how to get zsh to tab complete like paths past this point.
One of the DDEV sites I manage uses a database that includes a prefix. The default behavior for DDEV is to recreate the settings.ddev.php on every start. But that obviously overwrites anything added, purging any manual addition of the prefix.
Is the assumed solution to stop DDEV from overwriting the file? Or to create another settings file (like settings.local.php) to override what's been overridden? Or am I missing something?
This just seems like something that would exist as a simple variable in the config to generate a more accurate settings.ddev.php file. Thanks!
There are a few straightforward answers:
Don't let ddev fiddle with settings at all. Change the project type to 'php' and ddev won't mess with it.
Make the changes you want to db settings in settings.php after the inclusion of settings.ddev.php. That should work no matter what. And it should work on your prod site as well.
Do the work in settings.local.php, but include it after settings.ddev.php in your settings.php file
Take over settings.ddev.php and do whatever you want with it. This just means deleting the line that contains #ddev-generated in settings.ddev.php. After that, ddev won't muck with it at all.
I decided to use a version of the second suggestion:
// Automatically generated include for settings managed by ddev.
$ddev_settings = dirname(__FILE__) . '/settings.ddev.php';
if (getenv('IS_DDEV_PROJECT') == 'true' && is_readable($ddev_settings)) {
require $ddev_settings;
$databases['default']['default']['prefix'] = "drupal_";
}
I just added the $databases line. The rest was already there.
I am trying to use a filter rules file that uses wildcards for include/exclude lines to drive what gets included and excluded for running rsync to backup a server.
I am using the command line like:
rsync -avzh --filter="merge rsync_backup_filter" / user#backupserver:/backup-data
where rsync_backup_filter is currently something like
+ /var
+ /var/www
+ /var/www/webapp1/***
+ /var/www/webapp2/***
- /var/www/*/repo
+ /home/***
+ /etc/***
- *
but that filter rule syntax above is not quite right because the results don't actually match what I am intending. The repo sub folder is not excluded as I am trying to achieve.
I want to be able to use something like the last entry to say exclude anything not explicitly (using wildcards) included in the rules above
I want to be able to include certain paths (in the example above including webapp paths) and indicate that all files and folders below that point should be included but also be able to add exclusions within that previous wildcard (in the example above I want to exclude the repo subdir in any webapp path, so essentially saying "all except" in certain paths
Above is just a snippet and the longer version of the file would be a full backup strategy for the server from the root on
What is correct way to do structure the filter rules file and proper way to use wildcards to achieve what I've described?
Filter rules constitute an ordered set and evaluation continues until the first match occurs. So, all repo folders will be excluded, if you move the exclude rule up - at least to line #3.
I am writing a script which touches a file and afterwards modifies the access control list the way that one particular user (say peter) shall have full permissions to that file. Therefore I must add peter and a mask as well, if there was no one before.
For example
# file: newfile
# owner: hans
# group: hansgroup
user::rwx
user:peter:rwxc
group::r-x
mask::rwx
other::r--
The mask must give full permissions as well, otherwise peter's entry would be masked.
So, what if there is already a mask entry because there are other special user or group entries (which could come from a default ACL for the directory) - can I just change the mask to rwx in order to enable full permissions for my new peter entry? I am sure I would - in some cases - change the effective permissions of some other special entries if I extend the mask?
If no, don't I need to worry about the extension of the mask? Isn't that a problem?
If yes, I see a dilemma in it. What could I do?
I am familiar with this documentation of acls: http://www.suse.de/~agruen/acl/linux-acls/linux-acls-final.pdf
I'm working on a drupal 6 site at mydomain.com/drupalsite, and the designer has put a lot of hardcoded image paths in there, for instance a custom img folder in mydomain.com/drupalsite/img. So a lot of the site uses links to /drupalsite/img/myimg1.png.
Here's the problem -- the site is eventually moving to finaldomain.com, via pointing finaldomain.com to mydomain.com/drupalsite. So now paths like /drupalsite/img/myimg1.png will resolve to finaldomain.com/drupalsite/img/myimg1.png, instead of what should be finaldomain.com/img/myimg1.png. The finaldomain.com site has to point to that subdirectory so it hits the index.php.
My first instinct is to use an .htaccess file to replace the /drupalsite with "", but I've tried about a dozen different solutions and they haven't worked. My hack of a solution was to use some ln -s links but I really don't like it :) tia
Andrew
The best method, in hindsight, is to ensure folks use Drupal functions to make all links:
l (that's the letter L)
drupal_get_path()
base_path()
The l() function takes care of base path worries, and provides a systematic way to define your URL's. Using things like theme_image() plus the l() function are a sure win. Use the second and third functions above if you have to write your own <a> tags and for use inside theme functions like theme_image().
But for your current situation:
As regards Andy's solution, it would be better if you could limit your changes to certain database fields where you know the links are located.
So write a query to select all those fields (e.g. all body fields):
$my_query = db_query("SELECT vid, body FROM {node_revisions}");
This, for example, will get you every body field in the node_revisions table, so even your old revisions would have proper links.
Then run through those results, do str_replace() on each, and then write the changes back:
while($node = db_fetch_object($my_query)) {
$new_body = str_replace('what you have', 'what you want', $node->body);
db_query("UPDATE {node_revisions} SET body = '%s' WHERE vid = %d", $new_body, $node->vid);
}
I'd obviously try it on one record first, to make sure your code behaves as intended (just add a WHERE vid = 5, for example, to narrow it down to one revision). Furthermore, I haven't taken advantage of node_load and node_save, which are better for loading and saving nodes properly, so as to provide a more general solution (for you to replace text in blocks, etc.).
For your files, I'd suggest a good ol' sed command, by running something like the following from within your "sites" folder:
find ./ -type f -exec sed -i ’s/string1/string2/’ {} \;
Nabbed that from here, so take a look on that site for more explanation. If you're going to be working with paths, you'll either need to escape the / of the paths in your version of the sed command, or use a different sed separator (i.e. you can write s#string1#string2# instead of s/string1/string2/, so you could write s#/drupalsite/img/#/img# instead of s/\/drupalsite\/img\//\/img/ :-). See also Drupal handbook page for quick sed commands: http://drupal.org/node/128513.
A bit of a mess, which is why I try to enforce using the proper functions up front. But this is difficult if you want themers to create Drupal content but you don't want to give them access to the "PHP Filter" input format, or they simply don't know PHP. Proper Drupal theming, at any point past basic HTML/CSS work, requires a knowledge of PHP and Drupal's theme-related functions.
I've done this before by taking a full database dump, opening it in a text editor, and doing a global search and replace on the paths. Then on the new host, load the modified dump file, and it will have the correct paths in.
You could try Pathologic, it should be able to correct paths like this.