I am creating a Firefox extension that calls a Linux shared library via the js-ctypes mechanism. I want my extension to display debug information on a standard terminal by calling a function in my shared library which then simply calls printf() to display the debug string on a terminal.
However, my application has no terminal. So, is there a way my shared library can open, display and printf() to display such messages?
Yes, I know about the built-in error and browser windows. But for obscure reasons I want to send my debug messages in a terminal window.
So, how can my shared library open and display a terminal to printf() into?
Since you're on Linux anyway, when running Firefox from the command line, it will print some stuff to stdout (or was it stderr) already. Same on MAC. Windows may need the -console switch. Your library that was loaded via js-ctypes could just use printf() and/or fprintf(stderr,...). I seem remember using printf myself when developing js-ctypes stuff in the past.
You can also use dump in JS code. This will only ever dump to the terminal, but not the Browser Console.
Lastly the Components.utils.reportError enables you to print arbitrary messages to th global Browser Console (formerly Error Console). Cu.reportError is basically a shortcut to nsIConsoleService, which will also generate appropriate location information.
You should probably create a simple server that connects to a named pipe and reads data, then prints it to its stdout. It would just be a simple program that connects to a pipe (like a file), and reads from it.
You can use mkfifo to create the named pipe, and your javascript app can write to it, just like you would a file.
A related question is here: How to send a simple string between two programs using pipes?
You can use the command line mkfifo tool, or use the standard C function.
Related
I've watched videos and when people run this it works just fine. I also tried console.log and I get-- 'console' undefined. I have node.js installed
document is not a built-in part of JavaScript. It is part of the Web API provided by browsers which you get when you load your JS by using a <script> element in an HTML document in a web browser. You aren't doing that, and document doesn't have a log method anyway.
You're running your JS using Windows Script Host, which isn't that. WSH does not have a document.
You probably want either:
the WriteLine method
to not use WSH (Browsers and Node.js being more common ways to run JS)
You aren't running in a browser, there is no document (plus, it'd be console.log there too). You are running in Windows Script Host, you can use WScript.Echo instead. But I'd rather recommend you to run your code in a browser or node.js anyway, WSH isn't a very useful environment for learning modern JavaScript.
You wrote you have node.js installed, so the issue could be that you simply used the wrong command: it should be node and not start!
I'm hoping to adopt k6 for load testing, but I'm having trouble developing scripts for it. My primary use case is to check at each request to see if I'm receiving the correct headers and content and would like to inspect the response with a debugger.
I tried to run the script on its own by attaching the node inspect debugger (https://nodejs.org/api/debugger.html) but the file doesn't get executed because the import and export module keywords are unrecognized by this current version of node (8.7.0)
I'm also unable to find any documentation on how to debug these scripts.
There is no debugger support (currently known) for k6 scripting. It's manual debugging at this time.
k6 runs javascript (ECMA6) and has an API documented at http://k6.io
Sidenote: k6 is not node and will not work with node tooling.
I recently opened an issue about this - the need for a "debug" mode where detailed information about requests is printed to stdout.
https://github.com/loadimpact/k6/issues/331
To be clear, this issue is not about creating a "real" debugger, like gdb or similar, where you can step through script code, but rather a special mode of operation where lots of HTTP request information is being output to stdout in real time, to facilitate understanding exactly what is happening between client and server when your script code is executed.
I will probably try to implement something like this as soon as Emily (the maintainer) merges in some major CLI changes she is working on right now.
I am looking for the current path in image browser in Adobe Bridge CS4. I need the path in a terminal session. Internally, Bridge can be scripted with Javascript. The only interface to this mechanism is to be going through Applescript like this:
set js to "app.document.presentationPath;"
tell application "Adobe Bridge CS4"
set theResult to do javascript js
end tell
To run this command from a shell, I use osascript -e ….
However, do javascript does not return a value at all. Why?
By all rights, this should work as the JS returns the expected result and the Applescript is correct per the Dictionary. A similar problem exists when trying to run Applescript on Acrobat bundled with CS4. Whether or not this is an actual bug or an intentional misdirection on Adobe's part to get AS devs to move to JSX still remains debatable.
You can not use AppleScript with Adobe Bridge. But what you could do is use Photoshop and BridgeTalk to get the results from Bridge.
I am developing a Firefox extension and would like to call an external binary from it. It would be great if I could use standard input/output to communicate, so I am looking for the best (and simplest) possible option.
This is what I learnt so far:
nslProccess is not suitable, since I need to get string as a return value. nslProccess can provide exit codes only.
I could use XPCOM but I would prefer if I didn't need to modify code of the binary (it's C, BTW). I would also like to make the most portable solution possible.
Protozilla IPC looks like a solution, but I'm not sure if this project is maintained. Last commit was 10 years ago.
As I understood, this functionality is implemented in Enigmail, which uses command line gpg tool. Does anyone have some specifics on that?
From all I know, Enigmail uses a binary XPCOM component to achieve this, usually this isn't a viable solution for an extension. And communicating with another process via standard input/output isn't part of the Gecko platform. So I think that you have three options:
Use js-ctypes to call the necessary OS functions directly. E.g. on Windows you would call CreateProcess and specify handles for the standard input/output in the lpStartupInfo parameter. Of course you would also have to use OS functions to work with the streams. This quickly gets very hairy if you need to support multiple operating systems.
Use the shell to redirect output. See this answer on how running a command with the shell works on Windows, on Unix-like systems you would use "/bin/sh" instead of env.get("COMSPEC"). You could write the input data for your command line application into in.txt and then run the command foo < in.txt > out.txt - the output will be in out.txt when the command is done. Obviously, this will not work if you need to interact with the application while it is running.
You could change the application to use a different IPC approach, one that is supported by the Gecko platform. Typically that would mean using TCP sockets bound to localhost. Or you turn it into a dynamic library (.dll on windows, .so on Unix-like systems) and communicate with it via js-ctypes.
Are there any command-line Linux tools that can catch basic syntax errors and compile time errors in my Javascript files, even if said Javascript files are written for use in a web browser?
I typically code my Javascript at the same time I'm coding my server side code in say Ruby or Perl. It would save me significant time if I could partially test my client side Javascript the same way I test my server side Ruby and Perl -- on the command line, typically from within emacs. I'm not expecting to catch run time JavaScript errors on the server, just basic things like a mistyped variable name or an extra bracket somewhere or a runaway string, things that could be found before actually attempting to execute the code.
What I do now to test/debug Javascript is the usual cycle of "visit web app in browser; check Firebug or other console; back to emacs to fix errors; repeat." Doing that is certainly unavoidable for more complex types of errors (e.g. involving user and network interaction) but a garden variety syntax error could be caught and dealt with more quickly on the command line without loading up the browser.
I've looked a bit into some server side platforms like node.js, but they all seemed geared toward writing and executing server side code (so all of the client side specific bits in my code would presumably make it barf). I also found an emacs mode for javascript REPL but it doesn't seemed designed to do just basic compile checks - it basically loads the whole page via an external graphical browser and lets you monkey with it, which is precisely what I'm trying to avoid.
Things like YUICompressor effectively do a syntax check too.
This isn't a direct answer to your question as it is a GUI tool, but I'm a big fan of Aptana. It uses SpiderMonkey to compile your code in the background and give you red squigglies for syntax errors as you type. (It also does the same for HTML.) It also tries to give you intellisense for JS, but it is hit-or-miss. It is nice when it works.
Since I probably haven't convinced you to change your development environment, let's answer your question directly. Why not use the SpiderMonkey engine to throw together a command-line app that does what you're looking for? It looks easy enough to plug in. You won't even have to worry about the fact that you're guaranteed to get runtime exceptions (there will be no DOM objects in your environment) — you don't have to actually execute the script. Just call JS_CompileScript and check for success. (And then destroy the JSScript object, of course.)
Or, if you're lazy, you could try Rhino Shell, which is a command-line Java tool which executes JavaScript.
I find JSHint, + its vim plugin are very useful. Light weight of vim and still be able to track the syntax errors of the javascript. JSHint can also be used as a command line tool.
https://github.com/walm/jshint.vim
Javascript debugger with a console in chrome:
The Chrome browser has a javascript debugger can find JavaScript errors:
In Chrome click Tools -> JavaScript Console:
This is examining a JavaScript page with the following code:
var error(){
}
And it tells me what is wrong with it, unexpected '('.
Telling me I can't define a function like that on line 14 of my javascript file.
If you click on the link next to the error, it will take you to and highlight the line that has the error/warning.
I wrote quick-lint-js for this purpose. It points out syntax errors, among other things.
quick-lint-js integrates with several code editors, such as Vim and Visual Studio Code. It also has a UNIX-style command-line utility if you prefer.