Is it possible to decode a firefox addon from the XPI binding format to the native language XUL?
I am just trying to learn how to make a addon. So, I think if I can decode a Firefox addon then I can learn addon architecture!
XPI is simply put a ZIP file, so you can just extract its contents and read the files...
Most of the code that you will want to look at is in the extension's chrome directory, usually in a jar file. All you need is a file extractor that can extract zip files. Once you extract the xpi (it's just a zip file with an xpi extension), open the chrome subfolder and see what's there. If it's a jar file, extract it's contents (.jar files are also just zip files with a different extension). From there, there's probably a content folder, which should have most of the xul, css, js, etc.
Just learned there is also xpi-unpack and corresponding xpi-pack in Ubuntu (via sudo apt-get install mozilla-devscripts); seems to take unpacking of both .xpi and included .jar files into account..
Cheers!
Edit: note however, you may have permission problems with xpi-unpack; here's an example command line log I had:
user#PC:Desktop$ xpi-unpack colt.xpi colt-dir
Unpacking colt.xpi
Unpacking ./chrome/colt.jar
Unpacked xpi file.
user#PC:Desktop$ ls -la colt-dir/chrome/colt.jar\!/
total 16
drwxr-xr-x 4 user user 4096 2011-07-05 09:52 .
drwxr-xr-x 3 user user 4096 2011-07-05 09:52 ..
d--------- 2 user user 4096 2010-09-12 05:15 content
d--------- 25 user user 4096 2011-01-08 17:08 locale
user#PC:Desktop$ stat -c '%n %a' colt-dir/chrome/colt.jar\!/
colt-dir/chrome/colt.jar!/ 755
user#PC:Desktop$ stat -c '%n %a' colt-dir/chrome/colt.jar\!/content/
colt-dir/chrome/colt.jar!/content/ 0
user#PC:Desktop$ sudo chmod -R 755 colt-dir/chrome/colt.jar\!/
user#PC:Desktop$ ls -la colt-dir/chrome/colt.jar\!/
total 16
drwxr-xr-x 4 user user 4096 2011-07-05 09:52 .
drwxr-xr-x 3 user user 4096 2011-07-05 09:52 ..
drwxr-xr-x 2 user user 4096 2010-09-12 05:15 content
drwxr-xr-x 25 user user 4096 2011-01-08 17:08 locale
EDIT2: Actually, turns out other files may be lacking permissions too:
user#PC:Desktop$ ls -la colt-dir/
total 28
drwxr-xr-x 4 user user 4096 2011-07-05 09:52 .
drwxr-xr-x 5 user user 4096 2011-07-05 10:04 ..
drwxr-xr-x 3 user user 4096 2011-07-05 10:04 chrome
---------- 1 user user 1337 2011-06-23 00:05 chrome.manifest
drwxr-xr-x 3 user user 4096 2011-07-05 09:52 defaults
---------- 1 user user 1969 2011-06-23 00:05 install.rdf
---------- 1 user user 1275 2010-09-12 05:04 LICENSE.txt
user#PC:Desktop$ stat -c '%n %a' colt-dir/install.rdf
colt-dir/install.rdf 0
... so best to chmod everything: sudo chmod -R 755 colt-dir/ before trying to make changes and pack (as in xpi-pack colt-dir colt-2.xpi)
Related
I am trying to give myself root access to all the file in this folder and not have to sudo everything I want to run a command.
The file I am concerned with is pro
When I enter ls -l I get :
drwxr-xr-x+ 12 Guest _guest 384 13 Jan 14:56 Guest
drwxrwxrwt 9 root wheel 288 13 Jan 14:30 Shared
drwxr-xr-x+ 148 Santi staff 4736 1 Apr 17:13 pro
then I enter chmod 775 pro/
It doesnt seem to change the permssions. What can I do to fix this or why is the folder restricting permission even though I appear to be root?
drwxr-xr-x+ ...
the final + means that the file is governed by acl
see
apropos acl : give you the mans to consult
wikipedia
Access Control Lists on Arch wiki
The /sys/class/gpio can only be accessed as root by default. So I like that a new group gpio can use the files and directories under /sys/class/gpio. To achieve that I added the following lines to /etc/rc.local (I'm on Debian):
sudo chown root:gpio /sys/class/gpio/unexport /sys/class/gpio/export
sudo chmod 220 /sys/class/gpio/unexport /sys/class/gpio/export
So this gives write permissions to all the gpio group members. So they can now export and unexport pins fine.
The problem is they can't read/write the specific pin files after export (e.x. /sys/class/gpio/gpio17) beacause those are owned by root:root again.
How can I change that they are created by default as root:gpio too? I mean I can do that manually each time I export a pin. But that's a bit uncomfy.
UPDATE
According to larsks' answer I created the missing rule file. Now it partially works:
-rwxrwx--- 1 root gpio 4096 Jun 19 16:48 export
lrwxrwxrwx 1 root gpio 0 Jun 19 16:51 gpio17 -> ../../devices/soc/3f200000.gpio/gpio/gpio17
lrwxrwxrwx 1 root gpio 0 Jun 19 16:45 gpiochip0 -> ../../devices/soc/3f200000.gpio/gpio/gpiochip0
-rwxrwx--- 1 root gpio 4096 Jun 19 16:45 unexport
But for the ./gpio17/ I still get root:root:
-rw-r--r-- 1 root root 4096 Jun 19 16:52 active_low
lrwxrwxrwx 1 root root 0 Jun 19 16:52 device -> ../../../3f200000.gpio
-rw-r--r-- 1 root root 4096 Jun 19 16:52 direction
-rw-r--r-- 1 root root 4096 Jun 19 16:52 edge
drwxr-xr-x 2 root root 0 Jun 19 16:52 power
lrwxrwxrwx 1 root root 0 Jun 19 16:52 subsystem -> ../../../../../class/gpio
-rw-r--r-- 1 root root 4096 Jun 19 16:52 uevent
-rw-r--r-- 1 root root 4096 Jun 19 16:52 value
UPDATE 2
Okay I solved the problem. Because I installed Raspbian over the RaspbianInstaller I never went through the raspi-config tool. This seems to be a problem. Because I was also missing the /sys/device/virtual/gpio/ folder.
I followed this guide here: https://community.element14.com/products/raspberry-pi/f/forum/26425/piface-digital-2---setup-and-use#139528
And afterwards the permissions were correct (even for the pin-folders and their files value, direction, ...).
More common rule for 4.x kernels will be the following
SUBSYSTEM=="gpio*", PROGRAM="/bin/sh -c 'find -L /sys/class/gpio/ -maxdepth 2 -exec chown root:gpio {} \; -exec chmod 770 {} \; || true'"
The rule in the initial answer will fail to chown the exported gpio if there's a symbolic link in the path
UPD please beg in mind that when you export some GPIO via sysfs, you should wait for udev rule to fire and complete before you get desired access rights. The thing that worked for me was sleep about 100ms before trying to access GPIO files.
You can do this using udev rules, which can define actions to execute when the kernel instantiates new devices. Current versions of the Raspbian distribution for Raspberry Pi devices contain the following in /etc/udev/rules.d/99-com.rules:
SUBSYSTEM=="gpio*", PROGRAM="/bin/sh -c 'chown -R root:gpio /sys/class/gpio && chmod -R 770 /sys/class/gpio; chown -R root:gpio /sys/devices/virtual/gpio && chmod -R 770 /sys/devices/virtual/gpio'"
This ensures that entries under /sys/class/gpio are always available to members of the gpio group:
# ls -lL /sys/class/gpio/
total 0
-rwxrwx--- 1 root gpio 4096 May 6 23:36 export
drwxrwx--- 2 root gpio 0 Jan 1 1970 gpiochip0
-rwxrwx--- 1 root gpio 4096 May 6 23:37 unexport
# echo 11 > /sys/class/gpio/export
# ls -lL /sys/class/gpio/
total 0
-rwxrwx--- 1 root gpio 4096 May 6 23:37 export
drwxrwx--- 2 root gpio 0 May 6 23:37 gpio11
drwxrwx--- 2 root gpio 0 Jan 1 1970 gpiochip0
-rwxrwx--- 1 root gpio 4096 May 6 23:37 unexport
Update
Permissions are correct for individual pins as well:
# ls -Ll /sys/class/gpio/gpio11/
total 0
-rwxrwx--- 1 root gpio 4096 May 6 23:37 active_low
drwxr-xr-x 3 root root 0 May 6 23:36 device
-rwxrwx--- 1 root gpio 4096 May 6 23:37 direction
-rwxrwx--- 1 root gpio 4096 May 6 23:37 edge
drwxrwx--- 2 root gpio 0 May 6 23:37 subsystem
-rwxrwx--- 1 root gpio 4096 May 6 23:37 uevent
-rwxrwx--- 1 root gpio 4096 May 6 23:37 value
Expanding on the answer by #roman-savrulin, here's a simpler version.
There's no need to run the rule on REMOVE events, only ADD events. There's also no need to run 'find' as the udev environment will supply the exact path of the sysfs directory containing the new GPIO pin's files. You can also use 'chgrp' to change only the owning group, and symbolic modes in 'chmod' to only add the group-write permission bit.
You'll still have to wait for the completion of the rule processing before trying to open the pin's files, but the process should complete more quickly with a simpler rule which only touches the minimum number of files necessary.
SUBSYSTEM=="gpio*", ACTION=="add", PROGRAM="/bin/sh -c 'chgrp -R gpio /sys/${DEVPATH} && chmod -R g+w /sys/${DEVPATH}'"
Check the groups you belong to:
userk#dopamine $: groups
userk sudo dialout
If you belong to dialout the following, if not, comment.
userk#dopamine $: ls -l /dev/gpiomem
crw------- root root /dev/gpiomem
This file mirrors the memory associated with the GPIO device. The output of the command means that the owner of the file is the root user and the group that "owns" it is the root group. The 10 characters represent the file type and the permissions associated with it. The current configuration allows the owner of the file to read and write to the file.
You want to be able to read and write that file if you want to control the gpios.
One option would be to modify the group owner and make it match with the one you belong to (dialout in my case) and set the permissions in order to allow all users of that group to read and write the file.
Long story short:
userk#dopamine $: sudo chown root:dialout /dev/gpiomem
userk#dopamine $: sudo chmod 660 /dev/gpiomem
Wait! This setting won't be persistent and will vanish after reboot.
See this post for further info about the topic
For Ubuntu run.
sudo apt install rpi.gpio-common
I'm running Max OSX 10.9.3 and I'm trying to setup an SSHFS file-share between my MacBook Pro and a remote file system. However, when I try to do it, it doesn't work.
Strangely enough, it makes the target directory disappear. Has anyone else seen this happen? Is it a bug?
First see that I can ssh normally into the target machine:
% ssh remoteuser#XXX.XXX.XXX.XXX # <--- SSH to remote system works! See below.
remoteuser#XXX.XXX.XXX.XXX % ls -altr remoteDir
total 8
drwxr-xr-x 26 remoteuser remoteuser 4096 Jun 22 01:00 ..
drwxrwxrwx 2 remoteuser remoteuser 4096 Jun 22 01:08 .
remoteuser#XXX.XXX.XXX.XXX % exit
% # <--- Logged out of remote system
Next, I create a directory locally and verify it was created:
% pwd
/mnt
% ls
total 0
drwxr-xr-x 31 root admin 1122 Jun 18 18:34 ../
drwxr-xr-x 2 root admin 68 Jun 23 08:11 ./
% sudo mkdir share1
% ls
drwxr-xr-x 31 root admin 1122 Jun 18 18:34 ../
drwxr-xr-x 4 root admin 136 Jun 23 08:50 ./
drwxr-xr-x 2 root admin 68 Jun 23 08:50 share/
Now I try to setup the SSHFS share:
% sudo sshfs remoteuser#XXX.XXX.XXX.XXX:remoteDir /mnt/share1
remoteuser#XXX.XXX.XXX.XXX's password:
%
Ok. It seems to have worked. No errors. So let's see the share we created, shall we?
% ls
ls: share1: No such file or directory
total 0
drwxr-xr-x 31 root admin 1122 Jun 18 18:34 ../
drwxr-xr-x 3 root admin 102 Jun 23 08:12 ./
What? Not only is the File Sharing not working, but the share1 directory seems to have vanished! (Although the file system seems to know it is missing, which is weird).
Where did /mnt/share1 go and how do I setup this SSHFS?
SSHFS doesn't come with OS X AFAIK, so you should mention how you installed it. But I'm guessing sshfs is designed to be used with fstab or mount rather than be called directly. Try something like:
mount -t sshfs remoteuser#XXX.XXX.XXX.XXX:remoteDir /mnt/share1
I have the following bash script:
#!/bin/bash
run_python(){
cd "`dirname $1`"
python "`basename $1`" $2 >test.log
}
crypto_util=/home/dev/src/crypto/util.py
run_python $crypto_util "testpassword"
Somehow cd command fails saying:
cd: /home/dev/src/crypto No such file or directory. I am quite sure the directory exists.
On a side note if I do the following this fails too:
run_python(){
python "$1" $2 >test.log
}
Saying python can not open the file /home/dev/src/crypto/util.py because there is no such file.
Any idea why?
Here is the output of the ll command on the directory/file:
drwxr--r--. 2 dev root 4096 Jun 11 18:56 crypto
-rwxr--r--. 1 dev root 4934 Jun 9 10:50 util.py
Output of ls -llid /home/
654084 drwxr-xr-x. 4 root root 4096 May 8 10:52 /home
Output of ls -lid /home/dev/
924265 drwxr--r--. 4 dev root 4096 Jun 9 09:17 /home/dev/
Output of ls -lid/home/dev/src/:
924266 drwxr--r--. 9 dev root 4096 Jun 9 10:01 /home/dev/src/
Output of ls -lid/home/dev/src/crypto:
924333 drwxr--r--. 2 dev root 4096 Jun 11 18:56 /home/dev/src/crypto/
Output of ls -lid/home/dev/src/crypto/util.py:
924337 -rwxr--r--. 1 dev root 4934 Jun 9 10:50 /home/dev/src/crypto/util.py
some of those dirs don't have x permission bit set - those are needed for entering a directory. Your problem may be that your scripts are running with another user as owner than "dev". dev is the only user allowed to change to those directories.
Set the dirs to +x, and try again.
In terminal, I want to make a bunch of folders appear in a certain order. It isn't alphabetical, but in an unrelated order. When I do this:
mkdir this folder is going to be
The folders all show up correctly in Finder, but alphabetized. I have confirmed that the folder's view options are set to Sort By: None, Arrange By: None.
Is there a different way to accomplish this?
If you really want "no order" you will get unpredictable results. Seems like you want file creation date or file modification date (oldest first) order.
This command:
$mkdir this folder is going to be
is misleading, because you have no idea what algorithm 'mkdir' is using internally to create the folders (unless you read the source), so no idea what order is actually going to result, from the point of view of the filesystem (its not the order you expect).
To be clearer, you need to issue the command once per file
$ mkdir this
$ mkdir folder
$ mkdir is
$ mkdir going
$ mkdir to
$ mkdir be
then you can list in reverse modified-date order:
$ ls -tr
this folder is going to be
$ ls -ltr
total 0
drwxr-xr-x 2 user staff 68 6 Jan 20:41 this
drwxr-xr-x 2 user staff 68 6 Jan 20:41 folder
drwxr-xr-x 2 user staff 68 6 Jan 20:41 is
drwxr-xr-x 2 user staff 68 6 Jan 20:41 going
drwxr-xr-x 2 user staff 68 6 Jan 20:41 to
drwxr-xr-x 2 user staff 68 6 Jan 20:41 be
on the native mac filesystem hfs+ there is also a 'creation date' flag, which is probably what you want, but this is not very portable across other filesystems.
IN the finder, arrange by > date created
or arrange by > none, view in list view, with 'date created' column showing, and click on it.
You can't; folders are inherently not ordered.