This question already has an answer here:
My very simple Greasemonkey script is not running?
(1 answer)
Closed 6 years ago.
I am trying to get a Greasemonkey script to run on a page. But it does not.
How do you debug scripts?
What are the smallest possible baby-steps to start a new Greasemonkey script?
When I was starting with user scripts, my first error was not using wildcards.
// Broken:
// #include https://www.example.com/
// Working:
// #include https://www.example.com/*
That's the simplest way for the script to not even apply, and thus not run at all. In addition, make sure to check for syntax errors; a misplaced semicolon can prevent the script from being parsed, and thus it is ignored.
For me there was a syntax error in the script and Greasemonkey didn't give an error message. Copy-pasting the script to the JS Console revealed the secret.
you can write logs everywhere in your scripts to get better traces of what if being done in them:
GM_log("Hello, World!");
http://wiki.greasespot.net/GM_log
More info:
http://wiki.greasespot.net/Greasemonkey_Manual:Other_Useful_Tools#JavaScript_Console
Another tip: Take a look at the whole greasemonkey wiki. They have a lot of good stuff in there:
http://wiki.greasespot.net/Main_Page
In Firefox, open Tools > Error Console and watch it as you load the page. If you're getting overwhelmed by Warnings from the page you can filter on Errors, which still often highlights your script problem.
My greasemonkey script was working; I added a line; it stopped working; I removed the line; it still didn't work.
I determined that greasemonkey had installed a broken updater.php script when I reloaded the script with the new line added. Reloading the old script kept the broken version of the updater.php script. I eventually found an error message referring to the updater.php script in my Firefox Web console. I replaced the updater.php script with a file containing a comment after loading the new version of the script, and my script started being executed.
On mac, my updater.php was in: /Users/csimmons/Library/Application Support/Firefox/Profiles/81ri7k71.default/gm_scripts/Extended_LoU_Tweak
You may be able to find a similar updater.php file in your Firefox default profile gm_scripts/ directory.
Make sure that Greasemonkey is enabled in the first place:
Also, the syntax of #include is to have only one matching pattern. If you want another one, add another #include line.
If the URL of a page is set with Javascript instead of by navigating (like Instagram giving its popup windows a permalink URL), Greasemonkey will show the script as running but it actually won't start. Try reloading the URL and seeing if it actually goes to the same page. If not, you'll have to match the home page URL instead of the popup URL.
I had this trouble too; this was the solution for me:
Check the (and Modify the tricky) part of the code I was working on when it happen
uninstall and reinstall GreaseMonkey
then i got a real error report
EDIT: Today the probleme come more often than usually (new release?)
It looks like Firefox web tools are fighting with greasemonkey or JS engine for error messages.
So when you're looking somewhere (ctrl+alt+k) the error message appears somewhere else (try opening the other console) it's like a funny game.
Related
Premise: I coded a Tkinter GUI for a python script. It works. I can launch it from terminal. I created an icon and the icon will show up in my GUI just fine. I've been looking for tutorial on .desktop launchers and none of the examples I've found work. After a few hours of wading through SEO spam in SERPs trying to find a tutorial on the subject or a forum question that has been correctly answered. Finally I decided to join a forum ask a question. I've found a lot of code snippets on this site in the past. Figured I would try here.
I've tried about 20 different examples none of which have worked but I think I at least know the questions to ask. Here's an example of a .desktop file: It's not an example that works but it's one on found on this site so I figure I will start there.
[Desktop Entry]
Type=Application
Terminal=false
Icon=/path/to/icon/icon.ico
Name=ApplicationName
Exec=python3 /path/to/application.py
Categories=Application;
Note the example in the other post shows a red highlight over Categories=Utility; and when I try to change it in /usr/share/applications/ it makes gnome-terminal insert an A when hit the up key to get my last BASH entry and change a bunch of keys on my keyboard into hotkeys rather than being able to type it pops open print dialogs and things like that that which is wicked annoying.
Does anyone want to discuss what each entry line in a .desktop file is supposed to look like. Also does the application, icon, and everything have to be in /usr/share/applications? What file locations are ok to use in this type of file?
Something else I thought of; is it possible that my Exec line is not correct. Does exec have to be a single argument? Do I need to create a bash script that can be called by Exec that is just something like ./script.sh or should I create a command alias that is a single argument? Or does it actually matter?
I also have a Linux question: What package handles .desktop icons? Who maintains said package? And where can I find actual documentation on the subject?
I'm trying for the first time to use dzen on my setup, then on the Arch Wiki I came up with the section about clickable areas, to pipe the command into conky and then when I click the text on conky the dzen2 script would show up.
But the command on conky simply doesn't work. I tried writing every way but it doesn't. The wiki says the following:
Save this script and make it executable and then use the ^ca()
attribute in your conkyrc (or the script that you pipe to dzen2) to
trigger it.
^ca(1,)Sysinfo^ca()
But it does nothing. When I replace the path to my script it just shows this command in form of a conky text. If I execute my script on terminal it runs correctly, but this command on conky does nothing at all.
I had the same problem. In my case it was caused by installing it from some fork (actually, it's first page that is searched by google under dzen2).
Installing from robm github made it work.
I just started learning Node.js and I have the following question:
Is there an easy way to check variable, array, etc., values in the node.js command prompt or shell? For example, when writing normal javascript, I am used to opening up the browser's console where I can just type in the name of a variable to see its value.
How would I do this same thing when writing code in node.js? I know I can open the shell and write javascript, and then type in variable names and it will return their values, but how can I do this on the fly, as I'm writing an app?
Alright, I've figured this out...
Just as in front-end javascript development, you can input 'debugger;' into your .js file where you want to begin debugging. Then, from your command prompt, you would type:
node --inspect-brk [filename] [anything else required to call the function]
After this, open a tab in Chrome and type 'chrome://inspect' You should then see a link that reads 'Open dedicated DevTools for Node.' When you click this, you will be able to debug the program from Chrome, just as you normally would when working on browser-based programs. This works with nodemon as well, and you can leave this window open while working, no need to close/open for different files, etc.
Hope this helps someone else who is also new to Node!
There's quite a bit of information out there on this topic, but for some reason I just can't get it to work. This is on a raspberry pi running the 'DietPi' flavor over the raspian distro, and is perhaps what separates my question from the others.
So I have a GUI application that I wish to launch at boot, after the LXDE session has begun. So I have utilized the following file here:
/etc/xdg/lxsession/LXDE/autostart
and added the line:
#/myapplication
This works, however, it launches multiple instances of this program, and the first one always crashes. This creates problems because there's some competition for resources (IO, files, etc). So what I did was create script file, /myapplication-autostart.sh instead like so:
if pgrep "myapplication" > /dev/null
then
echo "my application is already running"
else
/myapplication
fi
and then changed /etc/xdg/lxsession/LXDE/autostart to #/myapplication-autostart.sh. Now what I find is the program launches once, but the instance crashes. It crashes when it attempts to create a window (opencv imshow). This is strange because the program will also run headless if an X-session is not available, but for some reason it crashes and I do not know where to check why.
Also, to test it wasn't an issue with the script file, I commented everything out except the /myapplication and I have found the script file runs in a continuous loop and every time I close the application it opens back up. I'm not sure why this is either.
I've tried adding a sleep delay in the script and it does not help. For whatever reason, it seems the LXDE autostart script is ran at least 3 times when booting the pi and the circumstances around the first cause the program to crash. Does anybody understand this sequence and behavior of calling this autostart script?
It is also possible to use the XDG standard Autostart - which is independent of the used desktop environment - by placing desktop files at
$XDG_CONFIG_HOME/autostart (by default ~/.config/autostart)
or for system-wide autostarts at $XDG_CONFIG_DIRS/autostart (by default /etc/xdg/autostart).
Such a .desktop-file could look like:
[Desktop Entry]
Type=Application
Version=1.0
Name=JDownloader
Exec=/usr/local/bin/my-application.sh
Categories=Utilities
The specification of desktop-files can be found at freedesktop.org.
Here was the final solution...
/etc/xdg/lxsession/LXDE/autostart added the line:
/myapplication-autostart.sh
and /myapplication-autostart.sh was changed to:
#!/bin/bash
if pgrep "myapplication" > /dev/null
then
echo "my application is already running"
else
if [[ "$DISPLAY" = ":0" ]]
then
/myapplication
fi
fi
I had to write the display variable to file in combination with the errors to file to discover the issue. At login 2 X sessions were created, display ":1" and display ":0", in that sequence. Display ":1" crashed because, although not headless, it was not initialized to a particular resolution and there was some resizing code in my program. Display ":0" was the actual display on the HDMI out and the one I wanted. Really, the conditional check to see if the application isn't necessary but I left it in there to be safe. I could have also left the # on the LXDE autostart file but it got annoying in the cases I wanted to close the application because it'd keep re-opening. Possibly I'll put it back later.
Thanks for the help!
First, some comments about opening several instances of the program: when you use "#" at the beginning of the line on the startup file (ex.: #/myapplication), this requests your system to try to launch the program, but if the program fails to open correctly, then the system will try to open it multiple times until it opens correctly -- if you remove "#" from the line beginning, then the system will only try to open the program once.
Now, to find out why the program is failing, I advise you to add
2> /file/log
to the end of every command on your script. Doing so would append any error message to a log (/file/log), and analyzing those error messages would be key to find out why the program is misbehaving.
One important note: if your program needs root privileges to run, then it will fail when called via /etc/xdg/lxsession/LXDE/autostart, as this method calls programs without elevated permissions.
This is an old thread but I was having problems getting autostart to start all the tasks listed. After many days I concluded there were one or more "invisible" characters that autostart didn't like. So I deleted the lines for the tasks that didn't start and retyped them. That solved the problem!
I think I corrupted the lines because I was editing some of the lines on my Windows computer. It was likely inserting CR with LF or some other stuff. I WILL NEVER EDIT TEXT FOR LINUX USING WINDOWS!
Maybe someone else will hit this problem and this may help them. I don't know where else to put this information.
I am writing a script on Red Hat Linux (I forget the version) that needs a header, but the banner command is not there for me to use and I won't be able to get it installed. I read via Google that it may well have been deprecated.
So is there a new version of the command that produces similar results, or a way I can replicate the command, or even just temporarily change the script output so that characters are a different size?
I've tried looking at stty but we don't access via xterm, we log in directly via putty.
In its simplest form, 'banner' is less than a few pages of code (e.g. this one). Perhaps you could just compile and run it from your home directory?
Use some web site, for example http://patorjk.com/software/taag/.
If you need it frequently you can create a script to scrap the result.
BTW, stty has nothing to do with your problem, I don't know why you mentioned it.