Adding a dictionary to Aspell/Pspell - php

I have Aspell successfully installed and have compiled PHP with Pspell, and everything seems to be working fine.
The only thing I am unable to do, is create a list of "ignore" words, or a personal dictionary, however you want to refer to it.
I've tried the steps outlined here and here but neither had any effect.
As described at the above link and on the Aspell documentation, I tried creating a personal dictionary as outlined in the manual:
personal_ws-1.1 en 0
Rubiflex
quasirhombicosidodecahedron
I placed this in the aspell directory, my home directory, the root directory, and it was never picked up. The Aspell documentation never actually says where it should live or how to otherwise load it.
The other reference is to creating an individual word list:
Create a txt file with the words that you'd like to add to the dictionary, where each word is on a separate line then run the following command:
aspell --lang=en create master ./custom.rws < test.txt
This will create a file called custom.rws that will contain the aspell encoded word(s) for the dictionary. You can name the file
anything you want as long as the extension is .rws. Now to add this
to the dictionary move the custom.rws file to the dictionary location
which is /usr/lib/aspell by running the following command:
cp custom.rws /usr/lib/aspell/
To finish adding it to the dictionary change into the dictionary directory by running the following:
cd /usr/lib/aspell/
then edit the following file: nano en_US.multi
and add the following line:
add custom.rws
Neither of these methods seemed to work and I cannot find any clear examples of how to properly add a dictionary or word list. These were the two most promising methods I was able to find and neither worked. Does anyone know how I can get Aspell to use a personal dictionary file I create?
Thank you for your time.
EDIT:
The steps outlined here worked for me. The are much like the ones outlined here except that the latter refers to "en_US.multi" where the former refers to "en.multi". After adding the custom list to en.multi (as opposed to en_US.multi), it was working as expected.

For my latest work onto the Perl's Text::Aspell module and code to determine the mother language of a Web visitor querying a company's search engine, I came across some of the pitfalls you describe (personal dictionary not implemented in Aspell6). However I worked it around using the 'extra-dicts' notion, one for each possible language.
I also had to workaround the fact that Aspell owns no dictionary for the Arabic, Hebrew, Japanese, Chinese and Korean languages. These languages are dealt with specifically.
You may view the full latest Perl's and bash codes for Linux and Windows running Windows/MinGW at http://vouters.dyndns.org/tima/Linux-Windows-Perl-Aspell-Determining_the_country_of_a_Web_query.html. You may use the URL links in the REFERENCES section of the document to adjust some of the Perl's code notions to PHP.

I was able to add a personal dictonary using option --add-extra-dicts to aspell call
aspell -c --add-extra-dicts=./custom.rws my_text_to_spell_check.txt
custom.rws has been created as depicted by OP:
aspell --encoding=UTF-8 --lang=<lang> create master ./custom.rws < test.txt
And remember to add --encoding opton to match the correct encoding for your source file.
I Hope this can help someone!

Using the aspell version below with Cygwin:
International Ispell Version 3.1.20 (but really Aspell 0.60.6.1)
it was looking for a personal dictionary named .aspell.en.pws in my home directory, regardless of what I specified on the command line with the --personal option. I was able to place a symbolic link named .aspell.en.pws in my home directory and let it point to a different location on my file system. I had to create the file first and add the required header before aspell would start adding to my personal dictionary.
In short, you can do this:
echo "personal_ws-1.1 en" > ~/my/file/location.pws
ln -s ~/my/file/location.pws ~/.aspell.en.pws

Related

Not a single PHP file is recognized as PHP file in PhpStorm

I really don't know what could cause such a strange behavior from mentioned editor. Literally all project files with .php extension are recognized as... text files I suppose. I know that stuff like that happens when the extension is forgotten during making of a PHP class for example, but I cannot explain why this appended to all files in the project.
I know that I can change file type of each individual class, but I'm doing a Laravel project and I can't manually change file type of every single default PHP class each time when I start a new project and each time I myself add a new class.
Is there any setting which defines rules for certain file types, since changing file types of every individual project file isn't a solution? At least, not viable one.
Every language is associated with one or more file extension patterns within the IDE.
Open File > Settings and then search for File Types and look for PHP in this case. There will be a list of Registered Patterns associated with PHP.
Ensure that *.php is in that list, or add it if it is missing.

Yocto doesn't copy libphp7.so to rootfs

To add the php apache2 module in Yocto I created a file recipes-devtools/php/php_%.bbappend with the following content:
PACKAGECONFIG = " mysql sqlite3 imap opcache openssl ${#bb.utils.filter('DISTRO_FEATURES', 'ipv6 pam', d)} apache2"
LIBS_pn-php =" -lpthread "
export LIBS
THREADS_pn-php = "pthread"
export THREADS
The module is built, but the file tmp-glibc/sysroots-components/cortexa7hf-neon-vfpv4/php/usr/lib/apache2/modules/libphp7.so is not copied to the rootfs (/usr/lib/apache2/modules/).
Why it does not deploy the file?
As temporary workaround (and to learn how to handle Yocto's path) I'm trying to manually deploy it with a ROOTFS_POSTPROCESS_COMMAND. To avoid absolute paths, what variable should I use to find out the file above under the tmp-glibc output dir? Something like:
${TMPDIR}/sysroots-components/cortexa7hf-neon-vfpv4/php/usr/lib/apache2/modules/libphp7.so
or there's something better?
In Yocto, files (which are installed in ${D} either manually in do_install or by the make, cmake, autotools, etc... in e.g. do_compile) are put in a package when they match one of the regular expression (or glob, not entirely sure about that) contained in FILES_foo.
One recipe can (and usually does) provide multiple packages. So you'd have multiple FILES_foo1 with their own paths to match.
In Yocto, the file is put in the first package where one of the paths in its FILE_foo matches the file. Even if the file matches the paths of other packages, it'll ever be in only one package, the first one.
FWIW, packages are created from leftmost to rightmost in PACKAGES variable in the recipe. By default, the PACKAGES variable is ${PN}-src ${PN}-dbg ${PN}-staticdev ${PN}-dev ${PN}-doc ${PN}-locale ${PACKAGE_BEFORE_PN} ${PN} (c.f. http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/conf/bitbake.conf#n292).
The default FILES_* variables are defined in bitbake.conf as well, c.f. http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/conf/bitbake.conf. Look for everything starting with FILES_.
In there, you can see that by default, FILES_${PN} has ${libdir}/lib*${SOLIBS} (c.f. http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/conf/bitbake.conf#n296) packaged. SOLIBS is, by default, .so.* (c.f. http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/conf/bitbake.conf#n280), which means only dot versions of libraries are packaged in the ${PN} package (if they are not matched by another package before).
FILES_${PN}-dev on the other hand packages ${FILES_SOLIBSDEV} which defaults to ${base_libdir}/lib*${SOLIBSDEV} ${libdir}/lib*${SOLIBSDEV}, with SOLIBSDEV in turns defaults to .so (c.f. http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/conf/bitbake.conf#n313, http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/conf/bitbake.conf#n314 and http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/conf/bitbake.conf#n283).
Please note that library filenames should all start with lib to be able to be matched by the default FILES_*.
TL;DR: By default, lib*.so.* in FILES_${PN} and lib*.so in FILES_${PN}-dev.
For your specific issue, you can see that ${libdir}/apache2 directory is packaged in php-modphp thanks to FILES_${PN}-modphp (c.f. http://git.openembedded.org/meta-openembedded/tree/meta-oe/recipes-devtools/php/php.inc#n243).
So you need to add php-modphp (assuming ${PN} resolves to php) to your image to be able for the lib to be installed in your rootfs.

Using a core Joomla component as a base for a custom component

I'm attmpting to pull all the necessary files that make up the Weblinks core componnent out of my Joomla 2.5 installation into a separate directory so that I can use it to make a custom component with additional fields.
My problems are:
I can't seem to figure out all the files needed to be pulled out in order to then successfull re-install the custom component
I can't seem to figure out all the renaming that needs to be done in the custom component in order to ensure it doesn't corrupt the core installation when I re-install it.
Has anyone done this before? I looked at creating a custom component from scratch and it seems like far too much workfor a non web developer. This also seems overkill in order to add a couple of fields.
Make a clean copy (off-root) of the component's folder structure as required by the component's manifest file (the xml in the administrator/components/com_weblinks).
This should be installable and complete to start with.
Now issue the following commands if you're on Linux or OSX; or download cygwin if you're on windows
grep -rl oldname . |xargs sed -i -e 's/oldname/newname/g'
grep -rl Oldname . |xargs sed -i -e 's/Oldname/Newname/g'
grep -rl OLDNAME . |xargs sed -i -e 's/OLDNAME/NEWNAME/g'
rename 's/oldname/newname/g' *
Make sure you renamed all occurences:
grep -rli oldname .
If nothing comes up, you're good to go; else, simply grep and pipe to sed as shown above. Make sure you never use case-insensitive replacements: that would definitely break your code.
Proofread the .xml manifest manually.
Repackage, and try installing. Read any error messages (or the error log if it's not clear), you should have little to no problems making an installable package). Installing repeatedly does not cause damage (unless you make naming mistakes in the .xml files).
P.S.: This answers your question, but maybe #David-Frisch's suggestion could be easier and more effective in your case, you get all the component structure set up in a neat and simple style, with little redundancy in the frontend editing features, but overall a great start. They moved to a new site.
You can create new component easily by using joomla's Official tutorials.
First you have to identify you requirement like your component required Front end and back end or sql tables etc.
The next step is to identify you requirement matching Joomla official tutorials That you can easily get from Articles in this series section.
At the end of that tutorial you can download a com_helloworld component.
Just unzip the package and rename all the occurrence of hellowolrd from the folder structure if you are using an IDE like Dreamweaver simply achieve this by using folder search options.
This will rename you complete com_helloworld folder contained helloword text .
The final step is to rename your files all the occurrence of your helloworld in your file you have set to new name of your component. and the folder too
Then zip the package and task completed.!
Hope this make sense..

Bash Script to Update Admin User Password for Multiple Drupal Sites on a Server spread over Multiple Versions

I have a server that runs quite a few Drupal sites. Some of these are older and running Drupal 5, while some are newer and running Drupal 6. We're also beginning to implement Drupal 7.
Our organization uses one standard Website Administration password that we distribute internally only to our employees for maintenance of these websites. This may or may not be the best security practice, but it is how we do things at this time. Please assume that this won't change.
The problem we have is that when we have employee turnover, we must change this password and apply the change to every site we run in order to make sure that the employee cannot deface any of our clients' sites. This is more critical for firings, but we also do it for resignations as a best practice.
In the past, I ran a basic PHP script that used mysql_list_dbs on our Database server to iterate through every database and change the pass field of the users table where the name = admin. BasicallY:
while ($row = mysql_fetch_object(mysql_list_dbs($sql_connection))) {
mysql_query("UPDATE users SET pass=MD5('$newpassword') WHERE name='admin'", $row->Database);
}
This worked perfectly fine but it has two problems:
It's hacky and I hate hacky stuff. I'd rather do things that make use of the "official way" of doing things
Drupal 7 uses a different hashing system than D5 and D6 did, so this won't work for Drupal 7 sites. Now I have to check first that the existing value of pass matches the hash of the old password before updating so that I don't accidentally break a Drupal 7 site. In the meantime, I haven't yet figured out how to implement this for Drupal 7 sites.
So I'm looking for an alternative solution. I really think that I need to use a bash script that either iterates through Virtual Hosts from httpd.conf or uses find or something and one way or another, cd's into every site install directory inside very installation platform's "sites" folder (we have a pretty messy setup*) and runs drush upwd admin --password=$newpassword
This would be completely platform independent and would allow Drupal to define what happens when the password is changed.
I realize that Aegir may actually be a good solution for this, but we're not ready to implement Aegir quite yet, and I'm looking for more of a quick and dirty intermediate solution. I appreciate any input you might have.
*Just a sample of our messy setup:
/www
/cliena
/drupal-5.x
/sites
/clienta.com <-- contains settings.php for Client A
/clientb
/drupal-5.x <-- contains old code base for Drupal 5 site that's been migrated I shoudld probably have my drush/bash script ignore these sections....
/drupal-6.x <-- contains code base for current Drupal 6 site
/sites
/clientb.com <-- contains settings.php for Client B
/clientc
/drupal-6.x
/sites
/default <-- contains settings.php for clientc.com
/sub1.clientc.com <-- contains settings.php for sub1.clientc.com
/sub2.clientc.com <-- contains settings.php for sub2.clientc.com
/sub3.clientc.com <-- contains settings.php for sub3.clientc.com
/client_sites
/drupal-5.x
/sites
/clientd.com <-- contains settings.php for clientd.com
/cliente.com <-- contains settings.php for cliente.com
/clientf.com <-- contains settings.php for clientf.com
... and so forth... you get the picture. a Migration to Aegir is in order, but it'll take a while to clean this up.
you could improve and continue writing this script bellow...
for FILE in $(find /www -type f -name system.module); do
C_PATH=`dirname $FILE`
C_VERSION=`grep "define('VERSION'," $FILE | awk -F "'" {'print $4'}`
print "--- DEBUG --- "
print "Current path: $C_PATH"
print "Current version: $C_VERSION"
# Your logic here...
done
[]'s
Felipe
The script of Felipe looks good, i adopted it, to deal with the multi-site-installations and drush. In my setup it found every site in my installation. Please try it with a not-so-destructive drush command first:
PASSWORD='secret'
for FILE in $(find /www/ -type f -name settings.php); do
PATH=`dirname $FILE`
echo "Changing password for: $PATH"
drush -r $PATH upwd admin --password=$PASSWORD
done
Felipe and Nebel54 both gave me great starts. I ended up working mostly off of Nebel's, but still had to make some modifications. I found two problems with your script, Nebel.
1) It seems that "PATH" is a reserved word. When I tried to use it as a variable, it didn't work right. So I changed it to "DPATH".
2) It seems that passing the -r parameter to drush isn't sufficient. When I used that, it told me that I needed a higher bootstrap level to run my command. So I had to do a CD to the $DPATH before executing my drush command.
For testing I executed the sql-connect command first because that just outputs the sql connection string for review and doesn't make any changes. I'm about to run the password update now. Here's my final script:
PASSWORD='newpass'
for FILE in $(find /www/ -type f -name settings.php); do
DPATH=`dirname $FILE`
cd $DPATH
echo "Changing password for: $DPATH"
drush upwd admin --password=$PASSWORD
done

how to create phpdoc Tutorial / Extended pages to supplement commented code

I'm trying everything I can to get phpdocumentor to allow me to use the DocBook tutorial format to supplement the documentation it creates:
I am using Eclipse
I've installed phpDocumentor via PEAR on an OSX machine
I can run and auto generate code from my php classes
It won't format Tutorials - I can't find a solution
I've tried moving the .pkg example file all over the file structure, in subfolders using a similar name to the package that is being referenced within the code .. I'm really at a loss - if someone could explain WHERE they place the .pkg and other DocBook files in relation to the code they are documenting and how they trigger phpdoc to format it I would appreciate it, I'm using this at the moment:
phpdoc -o HTML:Smarty:HandS
-d "/path/to/code/classes/", "/path/to/code/docs/tutorials/"
-t /path/to/output
I didn't expect to be answering my own question, but after 2 days of mind bending pain and a weekend to experiment it seems this is the problem:
The tutorial and my examples should work, but there seems to be a minor flaw in the way phpdoc interprets the switch values. Here is what I've been using:
phpdoc -o HTML:Smarty:HandS
-d "/path/to/code/classes/", "/path/to/code/docs/tutorials/"
-t /path/to/output
However if you use the following:
phpdoc -o HTML:Smarty:HandS
-d /path/to/code/classes/, /path/to/code/docs/tutorials/
-t /path/to/output
It will correctly format your tutorials and extending docs, all I did was drop the double quotes surrounding the directory paths. Single quotes don't work at all - as phpdoc itself wraps the directories in double quotes if there are no spaces ... this does seem like a bug with phpdoc, and the same behaviour occurred with the web based interface, so its an internal issue. my original attempt should have worked but didn't I will contact the developers and bring it to their attention.
Problem solved.
Have you read this?
It suggest the following path scheme: tutorials/package/package.pkg where package is the name of your package, did you do it this way?
I was experiencing the same issue using an .ini for configuration, but with me the problem was that I put a space in between the comma and the directory, which resulted in the directory not being 'linked' to the -d parameter.
Not working:
directory = {$lib}/Question,{$lib}/Error, {$path}/docs/tutorials
Working:
directory = {$lib}/Question,{$lib}/Error,{$path}/docs/tutorials
Hope this solves the problem for someone else!
Yes, your usage of the double quotes probably threw off phpDocumentor's internal runtime argument parsing, causing -d /path/to/code/classes to be one arg/value pair, without including /path/to/code/docs/tutorials as an additional directory value.
Typically, I've seen two other issues around tutorials not being created. One, the tutorial directory isn't what phpDocumentor expects. Two, no actual PHP code files are included in the execution. I remember adding verbiage to the manual specifically for these two scenarios.

Categories